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PREFACE 


Section  0. 
Preface 


A.  Forward .  Life  Cycle  Management  (LCM)  has  long  been  an 
established  set  of  procedures  in  the  development  of  BLM 
Automated  Information  Systems  (AIS).  These  procedures  have 
been  documented  at  various  times  in  several  different  ways 
but  have  not  been  consistently  followed  and  have  not  been 
formally  adopted  and  applied  throughout  the  Bureau. 

B.  Purpose .  To  formally  establish  LCM  as  a  procedure  that  will 
be  universally  followed  and  to  establish  a  mechanism  for 
periodically  reviewing  and  updating  the  procedure.  The 
benefits  of  LCM  are: 

1-  User  Satisfaction.  Users  will  better  understand  how 

the  system  will  operate,  how  controls  are  used,  and  how 
to  ensure  that  the  system  is  responsive  to  their  needs. 

2.  Accountability.  All  personnel  involved  will  understand 
the  ground  rules  for  standardized  development. 
Responsibilities  will  be  more  clearly  defined. 

3.  Control  and  Security.  Clearly  defined  responsibility 
and  procedures  will  ensure  proper  control ,  management 
check  points,  and  audit  trails. 

Utilization  of  Resources.  A  unified  staff,  in  a  common 
framework,  will  enhance  the  probability  that  an  AIS 
will  be  developed,  implemented,  and  operated  on  a 
cost-effective  basis. 

5.  Visibility.  A  formal  procedure  will  create  timely 
attention  from  top  management  on  personnel,  hardware, 
and  software  needs. 

6.  Productivity .  Clear  task  guidelines,  scheduled  review 
points,  and  disciplined,  consistent  procedures  will 
keep  everyone  working  toward  the  same  goal .  This 
should  eliminate  rework  and  wasted  effort. 

7.  Motivation .  Since  LCM  tasks  can  be  frequently 
measured,  timely  feedback  will  provide  both 
accountability  and  a  sense  of  achievement. 

8.  Scheduling .  Well  documented  design  specifications,  in 
user  terms,  helps  users  to  understand  the  total 
project,  minimizes  changes  to  the  scope  of  the  project, 
and  results  in  fewer  crises  and  less  rework. 
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9.  Screening .  Since  checkpoints  are  established  for 
management  review,  projects  which  do  not  meet 
requirements  can  be  terminated  prior  to  a  significant 
expenditure  of  time  or  money. 

10.  Documentation.  Project  documentation,  including  the 
Users  Guide  and  the  Operations  Guide,  is  required  as  a 
part  of  the  LCM  process. 
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How  to  Use  the  Manual. 


A.  Descript  ion .  This  guide  is  a  comprehensive  set  of  methods 
and  administrative  guidelines  to  help  develop  and  maintain 
effective  systems.  It  is  a  guide  for  managerial  action 
throughout  the  chronological  phases  which  make  up  a  system 
life  cycle.  Detailed  instructions  are  contained  in  other 
documents  such  as;  The  BLM  Manual;  GSA,  OBM,  and  DOI 
circulars  and  regulations;  the  Strategic  Plan  for  IS;  and 
various  IMs. 

B.  Organization .  The  guide  is  divided  into  chapters  covering 
each  particular  subject.  It  is  designed  to  follow  the 
chronological  steps  in  the  life  cycle  of  an  automated 
information  system. 

C.  Responsibility.  The  Office  of  Data  Systems  (D-200)  is 
responsible  for  the  development,  distribution,  and 
maintenance  of  the  LCM  Guide.  The  Deputy  Director, 
Administration  (800),  is  responsible  for  the  implementation 
of  the  procedure  and  for  scheduling  audit  and  review  to 
evaluate  the  effectiveness  and  to  uncover  any  deficiencies. 
The  Chief,  Division  of  IS  (870),  is  responsible  for 
coordinating  all  actions  necessary  to  ensure  that  these 
procedures  are  effectively  implemented. 

D.  Appl icabil ity .  Any  information  system  project  can  benefit 
from  the  application  of  these  procedures;  however,  past 
experience  has  demonstrated  that  short  term  or  small 
projects  should  not  require  full  formal  management. 

E.  Documentation:  The  goal  of  all  documentation  is  to  create 
and  maintain  effective  systems  at  the  lowest  cost. 
Documentation  costs  should  not  exceed  25%  of  the  total  cost 
except  in  special  situations.  The  documentation  levels 
presented  in  this  document  are  intended  to  be  guidelines  to 
help  scope  out  total  costs  and  to  prevent  over 
documentation.  (These  guidelines  are  modified  from  FIPS  PUB 
38.  ) 
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1.  Levels  of  Documentation. 

a.  Definitions  of  Levels. 

To  protect  against  both  over  and  under 
documentation,  computer  program  documentation  has 
been  divided  into  four  levels.  From  lowest  to 
highest  these  levels  of  documentation  are: 

(1)  minimal  level, 

(2)  internal  level, 

(3)  working  document^  level,  and 

(4)  formal  publication  level. 

The  criteria  determining  these  levels  of 
documentation  are  described  in  the  following 
paragraphs,  and  summarized  in  Figure  2. 

Additional  criteria  peculiar  to  an  installation 
and/or  judgment  relative  to  program  sharing 
potential,  life  expectancy,  and  usage  frequency 
are  also  appropriate  factors  to  be  considered  in 
the  determination  of  documentation  levels. 

(1)  Minimal  Level  (Level  1). 

Level  1  documentation  guidelines  are 
applicable  to  single  use  programs,  or 
one-shot  jobs,  of  minimal  complexity. 

Although  no  significant  documentation  cost 
should  be  added,  there  exists  the  requirement 
to  show  what  type  of  work  is  being  produced 
and  what  a  given  program  really  does.  Hence, 
it  is  desirable  to  keep  on  file,  for  a 
minimum  period  of  time,  the  documentation 
which  results  from  the  development  of  the 
programs;  i.e.,  program  abstract,  compile 
listing,  test  cases,  etc.  The  criteria  for 
categorizing  a  program  as  Level  1  can  be  its 
expected  usage  or  the  resource  expended  in 
its  generation,  in  man-hours  or  dollars,  and 
may  be  modified  for  the  peculiar  requirements 
of  the  installations.  Suggested  resource 
expenditure  criteria  are  programs  requiring 
less  than  two  work-months  effort  or  less  than 
$3,000  (these  are  not  assumed  to  be  equal). 


^  The  terms  "working  document"  or  "working  paper"  as  used  in  this 
(  ^  guideline  refer  to  typewritten  documents,  not  necessarilly  prepared  in 

finished  format  suitable  for  publication  nor  subject  to  external 
editorial  review. 


5 


INTRODUCTION 


Section  1  (Cent . ) 


HOW  TO  USE  THE  GUIDE 


(2)  Internal  Level  (Level  2). 

Level  2  documentation  applies  to  special 
purpose  programs  which,  after  careful 
consideration  of  the  possible  interest  of 
others,  appear  to  have  no  sharing  potential 
and  to  be  designed  for  use  only  by  the 
requesting  office.  Large  programs  which  have 
a  short  life  expectancy  also  fall  into  this 
level  .  The  documentation  required  (other 
than  Level  1 )  is  that  necessary  for  JCL  setup 
and  modifications.  This  requirement  can  be 
satisfied  by  the  inclusion  of  detail 
input/output  formats,  setup  instructions,  and 
the  liberal  use  of  comment  cards  in  the 
source  deck  to  provide  clarification  in  the 
compile  listing.  In  summary,  the  effort 
spent  toward  formal  documentation  for  Level  2 
programs  should  be  minimal. 

(3)  Working  Document  Level  (Level  3). 

This  level  applies  to  programs  which  are 
expected  to  be  used  by  a  number  of  people  in 
the  same  installation  or  which  may  be 
transmitted  on  request  to  other  installations 
or  to  contractors.  The  format  of  the 
documentation  at  this  level  should  include, 
as  a  minimum,  all  elements  of  documentation. 
All  basic  elements  of  documentation  should  be 
prepared  in  typewritten  form,  but  not 
necessarily  in  a  finished  format  suitable  for 
publication.  Normally,  it  will  not  be 
formally  reviewed  or  edited  above  the  review 
required  for  a  working  paper.  However,  if 
there  are  certain  programs  important  to  the 
activities  of  the  installations,  but  not 
considered  appropriate  for  publication,  then 
local  ,  more  stringent  documentation  review 
standards  should  be  applied. 


6 


INTRODUCTION 


Section  1  (Cont . ) 


HOW  TO  USE  THE  GUIDE 


(4)  Formal  Publication  Level  (Level  4). 

This  level  applies  to  programs  which  are  of 
sufficient  general  interest  and  value  to  be 
announced  outside  the  originating 
installation.  This  level  of  documentation  is 
also  desirable  if  the  program  is  to  be 
referenced  by  a  scientific  publication  or 
paper.  The  format  of  the  documentation  at 
this  level  should  contain  all  elements  of 
documentation  prepared  in  finished 
typewritten  format. 

Also  considered  to  be  within  this  level  are 
those  programs  which  are  critical  to  the 
activities  of  the  installation.  These 
programs  should  be  documented  in  a  formal, 
rigorous  manner ,  with  in-depth  review  and 
special  configuration  control  procedures 
enforced.  Recurring  management  applications, 
such  as  payroll,  should  be  considered  for 
inclusion  in  this  category  so  as  to  maintain 
an  accurate  history  of  conformation  to 
changing  laws,  rules,  and  regulations. 
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2.  Cost  and/or  Usage  Threshold  Criteria  for  Extent  and 
Formality 


Level 


1 


If  PROJECT  COST 


Less  than  $3000 
or 

two  work-months 


Then  Documentation 
Or  USAGE  1  ELEMENTS 


One  Shot 

(single 

use) 


System  Summary 
plus  any 
incidentally 
produced 
documentation . 


And  EXTENT  OF  EFFORT 


No  special  effort, 
normal  good 
practice . 


2 


$3000  to  $8000 


Special 

or 

Limited 

Purpose 

or 

Applica¬ 

tion 


Level  1  plus  Users 
Manual  and 
Operations  Manual 


Minimal  documentation 
effort,  spent  on 
informal 

documentation.  No 
formal  documentation 
effort . 


3 


Over  $8000 


Multi- 

purposed 

or 

Multi¬ 

user 


Level  2  plus 
Requirements  Study 
Program  Mainten¬ 
ance  Manual,  Test 
Plan,  Test  Result, 
and  System/Sub¬ 
system  Specifi¬ 
cation  . 


All  basic  elements 
of  documentation 
should  be  type¬ 
written,  but  need 
not  be  prepared 
in  finished 
format  for 
publication  or 
require  external 
edit  or  review. 


4 


Over  $8000 


Publicly 
Announ¬ 
ced,  or 
Critical 
to  Oper¬ 
ations 


Level  3  produced 
in  a  form  suitable 
for  publication. 


At  a  minimum,  all 
basic  elements 
prepared  for 
formal  publication 
including  external 
review  and  edit . 
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2.  Document  Requirements  by  Weighting. 

An  alternative  approach  to  determining  levels  of 
documentation  is  by  weighting.  Either  of  the  two 
methods  is  acceptable  in  determining  necessary 
documentation . 

This  scheme  uses  12  criteria  with  weighting  factors  and 
a  scale  of  the  total  weighted  criteria  to  establish 
documentation  requirements.  Figure  4  illustrates  the 
application  of  the  weighted  criteria  as  shown  in  Figure 
3.  The  procedure  to  use  these  tables  is: 

1.  Weight  the  software  by  the  criteria  in  Figure  3. 

2.  Sum  the  weights  assigned. 

3.  Find  the  row  in  Figure  4  that  lists  documentation 
required . 
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3.  An  Example  of  Weighting  for  Twelve  Documentation  criteria 


WEIGHTS 


Criteria 

1 

2 

3 

:  4 

5  . 

1 .  Original ity 
required 

None- re prog ram 
on  different 
equipment 

Minimum-more 

stringent 

requirements 

Limited-new 

interface 

; Cons iderable-appl  y 
existing  state  of 

Extensive -requires 
advance  in  state 
of  the  art 

2 .  Degree  of 
general ity 

Highly 
restricted . 
s ingle 
purpose 

Restricted- 
parameter¬ 
ized  for  a 
range  of 
capacities . 

Limited  — 
flexibility 
Allows  some 
change  in 
format . 

; Mul t i-purpose . 
Flexible  format 
;Range  of  subjects. 

Very  flexible-able 
to  handle  a  broad 
range  of  subject 
matter  on 

different 
equipment . 

3.  Span  of  operation 

Local  or 
utility 

State  wide 

More  than 

one  state. 

All  states 

Bureau-wide  — 

4.  Change  in  scope 
and  objective 

None 

Infrequent 

Occas ional 

Frequent 

Continuous 

5.  Equipment 
complexity 

Single  machine 
Rout ine 
processing 

Single 
mach ine . 

Rout ine 
processing . 
Extended 
peripheral 
system. 

Multi¬ 
computer  . 
Standard 
peripheral 
system . 

Mul t i-computer . 
Advanced 
programming . 

Complex  peripheral 
system. 

Master  control 
system.  Multi¬ 
computer  auto 
input/output  and 
display  equipment . 

6.  Personnel 

i  1-2 

3-5 

5-10 

10-18 

18  and  over 

assigned 
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Criteria 

1 

2 

3 

4 

5 

7.  Developmental 
cos  t 

1-lOK 

10-50K 

50-200K 

200-500K 

Over  500K  — - 

8.  Criticality 

Data 

processing 

Routine 
operat ions 

Regulatory 

requirement 

Critical  to  Bureau 
operations 

Major  Bureau  ^ 

program 

9.  Average  response 
time  to  program 
ch  ange 

2  or  more 

weeks 

1-2  weeks 

3-7  days 

1-3  days 

1-24  hours  ^ 

10.  Average  response 
time  to  data  inputs 

2  or  more 

weeks 

1-2  weeks 

1-7  days 

1-24  hours 

0-60  minutes  — 

1 1 .  Programming 

1  anguages 

High  level  — 
language 

High  level 
and  limited 
assembl y 
language 

High  level 
and  exten¬ 
sive 

assembly 

language 

Assembly  language 

Machine  language  1 

12.  Concurrent 
software 

None 

Limited 

Moderate 

Extensive 

Exhaustive  —  ^ 

devel opment 
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4.  Total  Weighted  Documentation  Criteria  vs  Required  Document  Types 


TOTAL 

WEIGHTED 

CRITERIA 

System 

Narra¬ 

tive 

Users 

Manual 

Operat  ions 
Manual 

Program 

Main¬ 

tenance 

Manual 

Test 

Plan 

Require¬ 

ments 

Study/ 

User 

Require¬ 

ments 

Document 

System/ 

Subsystem 

Design 

Specifi¬ 

cations 

Test 

Results 

Devel¬ 

opment 

Pro¬ 

ject 

Pro¬ 

posal 

Data  Base 
Specif i- 
cat ions 

Disaster 

Recovery 

Plan 

0-12* 

X 

X 

12-15* 

X 

X 

X 

12-26 

X 

X 

X 

X 

X 

* 

kk 

X 

*** 

24-38 

X 

X 

X 

X 

X 

X 

■k 

kk 

X 

*** 

36-50 

X 

X 

X 

X 

X 

X 

X 

X 

X 

*** 

kkk 

48-60 

X 

* 

X 

0 

X 

0 

0 

X 

NOTES: 

*  Additional  document  types  may  be  required  at  lower  weighted  criteria  totals  to 
satisfy  local  requirements. 

**  The  Test  Analysis  Report  logically  should  be  prepared,  but  may  be  informal. 

***  Preparation  of  the  Disaster  Recovery  Plan  and  Data  Base  Specification  is 
situational ly  dependent. 
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System  Life  Cycle. 

Computer  programs  and  automated  data  systems  evolve  in  phases 
from  the  time  an  idea  to  create  the  software  occurs  through  the 
time  that  the  software  produces  the  required  output.  It  is 
recognized  that  there  are,  in  current  usage,  many  different 
terminologies  to  identify  these  phases  and  the  stages  within 
these  phases. 

A.  Phases. 

Three  phases  applicable  to  the  software  life  cycle  are: 

1.  Initiation.  During  the  Initiation  Phase,  the 
objectives  and  general  definition  of  the  requirements 
for  the  software  are  established. 

2.  Deve lopment .  During  the  Development  Phase,  the 
requirements  for  the  software  are  determined  and  the 
software  is  then  defined,  specified,  programmed,  and 
tested.  Documentation  is  prepared  within  this  phase  to 
provide  an  adequate  record  of  the  technical  information 
developed. 

3.  Operation.  During  the  Operation  Phase  the  automated 
system  is  placed  into  a  production  status  and  the 
software  is  maintained,  evaluated,  and  changed  as 
additional  requirements  are  identified. 

B.  Stages. 

The  Development  Phase  is  further  subdivided  into  four 

stages . 

1 .  Planning/Definition.  During  the  Planning/Definition 
Stage,  the  functional  and  data  requirements  for  the 
software  are  determined. 

2.  Design /Specific at  ion.  During  the  Design/Specification 
Stage,  the  design  alternatives,  specific  requirements, 
and  functions  to  be  performed  are  analyzed  and  a  design 
is  specified . 

3.  Programming .  During  the  Programming  Stage,  the 
software  is  coded  and  debugged.  Documents  which  may  be 
prepared  during  this  stage  include  the  Users  Manual , 
Operations  Manual,  Program  Maintenance  Manual,  and  Test 
Plan . 
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Test .  During  the  Test  Stage j  the  software  is  tested 
and  related  documentation  reviewed.  The  software  and 
documentation  are  evaluated  in  terms  of  readiness  for 
implement at  ion . 


The  System  Life  Cycle  is  for  use  on  all  projects  varying  from 
very  small  and  simple  to  large,  complex,  multi-team  efforts. 


Development  Phase-Planning/Definition 


Initiation  Phase 

k 

System  Narrative 

* 

Data  System  Request 

k' 

System  Description 

-k 

Requirements/Feasibility  Study 

k 

Functional  Flowchart 

k 

Cost  Factors 

k 

k 

Integrated  System  Environment  Chart 
System  Assumptions/Constraints 

Development  Phase-Design/Specifications 


Operation  Phase 

k 

Detailed  System  Descriptiop 

* 

System/Program  Transfer 

k 

Modular  System  Flowchart 

* 

Processing  Priority 

k 

Input/Output  Requirements 

k 

Processing  Schedule 

(Data  Communications) 

k 

Preprocessing  and 

k 

System  FilesTData  Sets 

Postprocessing 

k 

File  Design  (Data  Base) 

Job  Management 

k 

System  Logic 

k 

Computer  Processing  Job 

k 

System  Controls 

Management 

k 

Computer  Processing 

k 

Data  Entry  Job  Management 

k 

Development /Implementation  Schedule 

* 

System/Program  Recovery  File 
Management 

* 

Glossary  of  Terms /Abbreviations 

T 


Development  Phase  -  Test 


Development  Phase  -  Programming 


k 

Program  Test  Data 

k 

fJajr^tive  Program  D^iription 

k 

Prograni  Test 

k 

Program  Logic  Flowchart 

k 

System  Test  Data 

k 

Techniques /Tables 

k 

System  Test 

k 

Input /Output 

k 

Test  Schedule 

k 

Control  Information 

k 

Performance  Criteria 

k 

Code/Compile 

k 

^s^  Procedures  . 

k 

Operations  Manual 

k 

System/Program  Test  Documentation 

k 

Program  Maintenance  Manual 

k 

UsersTlanual 
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Section  3. 

Project  Teams . 

A.  General .  Project  teams  draw  together  those  skills  that  are 
required  for  each  application.  The  teams  are  made  up  of 
analysts,  programmers,  users,  etc.,  with  the  best  available 
mix  of  skills  and  knowledge  for  a  particular  application. 
Individuals  may  be  assigned  to  more  than  one  project  team, 
dependent  upon  the  amount  of  work  and  timing  required  per 
project . 

Combinations  of  the  ideas,  skills,  work,  and  problem-solving 
contributions  of  all  individuals  on  a  team  will  add  up  to  a 
total  systems  result  superior  to  the  best  anyone  can  do  on 
their  own. 

Such  superior  results  become  stronger  as  project  teams 
utilize  special  skills  of  personnel  throughout  information 
systems  and  the  user  community.  Project  teams  bring  the 
strengths  of  the  entire  Division  to  bear  effectively  upon 
each  project,  large  or  small. 

B.  Project  Team  Authority.  Project  team  authority  consists  of 
one  simple  rule  -  Any  project,  once  defined  and  then 
approved  under  Division  management  procedures,  will  proceed 
to  completion  under  project  management,  unless  Division 
management  changes  or  stops  the  project.  Summarized,  the 
rule  is  -  Go  until  stopped. 

Execution  of  this  rule  requires  controlled  management 
interaction  with  each  project,  plus  the  absolutely  rigid 
precept  that  the  project  team  must:  Recognize  problems  on  a 
weekly  basis  and  start  the  solution  to  these  problems  during 
the  week  of  discovery. 

The  controlled  management  device  for  interaction  with  each 
project  will  be  based  on  FIPS. 
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The  FIPS  inaaa£,ement  device  will  be  the  System  Life  Cycle 
with  phases  of:  laitiatioa,  Developmeat , 

(Plaaaiai^/Def iaitioa ,  Desisa/Specif icatioa ,  Prostammin^, 
Test),  aad  Operatioas .  Within  the  software  life  cycle, 
modular  design  will  be  the  project  team's  key  to  ^ood 
communications,  work  delesation,  control  over  changes,  and 
control  of  levels  of  documentation. 

As  an  aid  in  bringing  all  necessary  skills  of  the  Division 
to  each  project,  the  walk-throuijh  team  concept  will  be 
applied  simultaneously  at  the  end  of  each  phase  and  the 
beginning  of  the  next  phase . 

C.  Project  Evaluation  and  Review.  Weekly,  the  project 

coordinator  will  report  progress,  dates  for  completion, 
problems  and  solutions,  and  problems  that  are  anticipated  to 
Division  management.  Reports  to  other  organizational  units 
(WO-670,  Field  Committee,  Steering  Committee)  will  be  as 
established  in  the  project  plan.  The  rule  of  management  by 
exception  will  be  followed. 

Division  management's  concurrence  with  all  activity  as  shown 
in  the  project  management  weekly  report  will  be  assumed 
unless  management  otherwise  directs.  This  practice  is  the 
implementation  of  the  rule  -  Go  until  stopped. 

Typical  uses  of  the  project  system  might  be:  The  project 
team  meets,  discusses  a  problem,  decides  what  to  do  about 
the  problem,  and  projects  the  result  upon  project  schedules. 
If  satisfied,  the  changed  data  (management  by  exception) 
would  be  sent  to  the  Branch  Chief .  The  Branch  Chief  may 
agree  but  finds  the  total  work  load  represented  by  all 
projects  adds  up  to  too  much  work  for  two  individuals  one 
month  from  now.  The  Branch  Chief  shifts  one  project  and 
advises  the  Project  Coordinator.  The  result  is  satisfactory 
to  the  Project  Coordinator  and  the  Branch  Chief  so  the 
change  is  sent  to  the  Division  Chief. 

The  Division  Chief  finds  that  the  Division  doesn't  have 

enough  resources  for  all  of  the  projects,  selects  one  to  be 
canceled  or  held,  and  tests  his  solution.  Branch  Management 
and  the  Division  Chief  agree,  so  the  Division  decision  is 
made  to  scrap  the  project . 
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(Cent . ) 

Team  Members .  Each  team  member  plays  an  important  role 
throughout  the  life  of  a  project,  and  the  absence  of  any  one 
member  can  seriously  degrade  the  outcome  of  the  project- 
Project  Manager.  The  project  will  be^in  with  the 
appointment  of  a  Project  Manager-  This  person  is  the 
formal  coordination  and  control  point  for  all 
activities  of  the  project.  He  or  she  meets  with  both 
^roup  and  individual  users,  maintaining  daily  contact 
so  that  the  users  are  cognizant  of  all  major  events- 
The  Project  Manager  makes  a  formal  report  to  management 
on  at  least  a  monthly  basis-  This  report  shows  the 
status  of  each  activity  and  includes  recommendations 
and  requests  for  any  assistance.  The  Project  Manager 
is  responsible  for  the  coordination  and  notification  of 
meetings  involving  the  User,  the  Analyst,  the 
Programmer,  the  Data  Base  Administrator,  and 
Management  - 

2.  User  -  The  User  initiates  the  effort  with  Development 
Project  Proposal  (DPP)  and  should  be  available  to 
assist  other  team  members  throughout  the  life  of  the 
project.  The  User's  presence  is  necessary  at  all 
meetings;  and  it  is  vital  that  the  User  take  part  in 
the  evaluation  of  test  results.  When  he  or  she  is 
satisfied  with  the  test  results,  the  system  is  formally 
accepted  - 

3.  Analyst  -  The  Analyst  assists  the  Project  Manager  in 
coordination  and  control  or  may  actually  be  the  Project 
Coordinator.  The  Analyst  counsels  and  advises  other 
team  members  and  participates  in  all  phases  of  the 
System  Life  Cycle.  He  or  she  is  responsible  for  the 
overall  system  design  as  well  as  the  system  testing  and 
acceptance  of  the  system. 

Proarammer .  The  Programmer  may  participate  in  the 
design  stage  of  the  project  providing  input  relative  to 
the  technical  state  of  the  art-  The  Programmer  is 
responsible  for  the  coding  and  testing  of  the  programs 
and  interfaces  with  all  other  team  members  while 
accomplishing  this  task. 
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5-  Data  Base  Manager.  The  Data  Base  Manager  participates 
with  development  teams  in  all  phases  of  the  System  Life 
Cycle.  The  Data  Base  Manager  interfaces  with  all  team 
members  providing  assistance,  information,  and 
counseling  as  required.  Throughout,  the  role  of  the 
Data  Base  Manager  is  that  of  consultant  and  advisor. 
Computer  Operations.  During  development  and  testing, 
Computer  Operations  interfaces  with  the  Project 
Coordinator,  the  Data  Base  Manager,  the  Analysts,  and 
the  Programmers. 

The  interfaces  of  the  team  members  are  many  and  complex.  It  is 
also  highly  probable  that  some  members  such  as  the  Data  Base 
Manager  and  Op)erations,  may  simultaneously  be  members  of  several 
teams  involved  in  project  efforts. 
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Section  4. 

Walk-Through  Teams . 

A  walk-throufeh  is  a  ^roup  review  of  some  phase  of  a  project's 
development  for  the  purpose  of  detecting  errors •  No  managers  are 
present  during  the  walk-through  since  the  ^oal  is  for  the  peer 
^roup  to  detect  errors.  The  person  responsible  for  the  work 
beiOf,  reviewed  is  also  responsible  for  conducting  the 
walk-through . 

Walk-through  teams  will  be  responsible  for  providing  objective, 
positive-tone  critiques  and  suggestions  to  project  teams  at 
controlled  intervals  during  the  System  Life  Cycle.  A 
walk-through  team  will  conform  to  the  project  rule  of  Go  until 
stopped'  by  referring  unresolved  action  recommendations  to 
management  as  an  accompanying  document  to  weekly  project 
evaluation  review  reports. 

Walk-through  teams  will  review  planning  at  the  beginning  of  each 
phase  of  the  System  Life  Cycle,  and  will  review  progress  at  the 
end  of  each  such  phase . 

The  personnel  makeup  of  each  walk-through  team  will  be  suited  to 
each  project  and  to  each  phase  of  each  project,  thus  fully 
utilizing  all  skills  of  the  Division  of  each  customer •  Users 
will  be  a  part  of  each  walk-through  team. 

When  a  project  team  must  solve  a  problem  during  a  phase  of  the 
System  Life  Cycle,  and  that  problem  requires  skills  beyond  the 
assigned  members  of  the  project  team,  the  walk-through  team 
assigned  to  that  phase  will  be  convened  to  assist  in  solution 
development . 

The  members  of  the  project  team  will  also  function  as  part  of  the 
walk-through  team. 
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Section  5. 

System  Life  Cycle  Coordination  and  Control- 

This  section  will  discuss  the  System  Life  Cycle  Coordination  and 
Control  Document,  its  use  and  preparation,  and  give  a  brief 
overview  of  the  phases  of  the  System  Life  Cycle  as  applicable  to 
automation  projects.  Further  detail  regarding  these  phases  and 
the  duties  and  responsibilities  of  the  team  members  is  provided 
in  the  following  sections. 

A.  Purpose .  The  purpose  of  the  System  Life  Cycle  Coordination 
and  Control  Document  is  to  control  and  document  the  required 
entities  related  to  project  development. 

The  document  contains  a  table  of  entries  covering  all  points 
to  be  coordinated  and  controlled. 

Down  the  left  side  of  the  document  the  persons  or  functions 
are  listed.  Across  the  top  of  the  document,  the  entries 
cover  the  tasks  to  be  completed.  The  document  will  record 
the  status  of  each  project  effort  and  the  status  of  each 
individual  part  of  each  project.  For  a  very  large  project, 
several  of  these  forms  may  be  needed.  Perhaps  one  at  a  high 
level  for  the  overall  control  and  others  at  a  detailed  level 
for  sub-parts  of  the  project. 

B.  How  to  Use  the  Form.  The  form  is  initiated  by  the  Project 
Coordinator  at  the  beginning  of  the  effort,  and  is  active 
for  the  life  of  the  project. 

The  form  should  be  initialed  and  dated  by  the  responsible 
party  as  each  task  is  completed. 

The  form,  when  properly  prepared,  will  document  both  the 
tasks  to  be  performed  and  persons  or  functional  units 
involved . 

C.  A  brief  explanation  of  the  illustration  follows: 

1.  Initiation  Phase.  The  objectives  and  general 

definition  of  the  requirements  for  the  software  are 
established . 

a.  Development  Project  Proposal  (DPP).  The  effort  is 
initiated  by  the  user  with  a  DPP.  This  work  may 
be  coordinated  with  data  processing. 
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b.  Approval .  A  review  and  evaluation  of  the  request 

is  performed  by  data  processing  and  presented  to 

management  for  approval . 

2.  Development  Phase.  The  requirements  for  the  software 
are  determined  and  the  software  is  then  defined, 
specified,  programmed,  and  tested.  Documentation  is 
prepared  within  this  phase  to  provide  an  adequate 
record  of  the  technical  information  developed, 
a .  Planning  Stage. 

1)  Definition.  Functional  and  data  requirements 
for  the  software  are  determined. 

2)  Walk-Through.  A  review  and  evaluation  of  the 
Planning  Stage  is  conducted  by  members  of  a 
walk-through  team. 

3)  Approval.  Upon  completion  of  the 
walk-through  the  Planning  Stage  must  be 
approved  by  the  user  and  management. 

b  ..  Design  Stage. 

1)  Specifications.  The  design  alternatives, 
specific  requirements,  and  functions  to  be 
performed  are  analyzed  and  a  design  is 
specified. 

2)  Walk-Through.  A  review  and  evaluation  of  the 
Design  Stage  is  conducted  by  members  of  a 
walk-through  team. 

3)  Approval.  Upon  completion  of  the 
walk-through  the  Design  Stage  must  be 
approved  by  the  user  and  management. 

c  .  Programming  Stage. 

1)  Coding.  The  software  is  coded  and  debugged. 

2)  Documentation.  Documents  which  may  be 
prepared  during  this  stage  include  the  Users 
Manual,  Operations  Manual,  and  Program 
Maintenance  Manual . 

3)  Walk-Through.  A  review  and  evaluation  of  the 
Programming  Stage  is  conducted  by  members  of 
a  walk-through  team. 

4)  Approval.  Upon  completion  of  the 
walk-through  the  Programming  Stage  must  be 
approved  by  management . 
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d .  Test  Sta^e. 

I)  System/Prosram(s)  Software.  The  software  is 
tested  and  related  documentation  reviewed. 

The  software  and  documentation  are  evaluated 
in  terms  of  readiness  for  implementation. 

Y)  Walk-Through.  A  review  and  evaluation  of  the 
Test  Stage  is  conducted  by  members  of  a 
walk-through  team. 

3)  Approval.  Upon  completion  of  the 

walk-through  the  Test  Sta^e  must  be  approved 
by  the  user  and  management. 

3.  Operation  Phase.  Upon  completion  of  the  Test  Stage  the 
system  is  placed  into  a  production  status,  and  the 
software  is  maintained,  evaluated,  and  changed  as 
additional  requirements  are  identified. 

a.  Production  Turnover.  Assure  that  all  system  and 
program  documentation  is  complete ,  and  that  the 
system  can  be  operated  in  the  manner  specified  by 
the  documentation. 

b.  Approval.  The  production  system  must  be  approved 
by  the  user  and  ADP  management • 
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INTRODUCTION 


Section  0. 
Introduction 


During,  the  Initiation  Phase,  the  objectives  and  general  definition  of 
the  requirements  for  the  software  are  established. 


Approval 


Development  Project  Proposal 


Walk.-Throug,h 


/ 


Cost  Factors 


Data  Systems  Request  (B) 


Initiation  Phase 


Requirements  Study: 
Present  System 


*Feasibility  Study: 
Economic  Considerations 


*Feasibility  Study: 
Technical  Considerations 


Requirements  Study: 
Proposed  System 


^Feasibility  Study: 
Mandatory  Considerations 


*  As  Required. 
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Section  1. 

Development  Project  Proposal 

A.  Purpose.  The  Development  Project  Proposal  (DPP)  (Form  No. 
1181-1)  provides  a  convenient  method  to  document  a  request 
for  services.  The  DPP  provides  sufficiently  detailed 
information  to  enable  management  to  review  and  evaluate  the 
request  within  the  established  constraints  and  scope  of 
their  responsibility. 

Responsibility.  The  requesting  organization  and/or  the 
Project  Coordinator  will  have  primary  responsibility  for  the 
preparation  of  the  DPP.  The  Office  of  the  Chief,  Division 
of  Information  Systems  will  assign  DPP  numbers. 

C.  Contents .  The  DPP  is  designed  for  the  requestor  to  describe 
the  request  in  terms  of  results.  Assistance  is  available 
from  I.S.  personnel. 

D .  DPP  Preparation  Instructions 

1-  Objective  Statement.  Include  in  this  section  a  concise 
description  of  the  request.  It  must  contain  the 
objectives  and  the  organizations  affected. 

2.  Justification.  Clearly  state  the  reasons  for  the 
proposal,  show  expected  benefits  and  cost  savings. 

3.  Project  Plan.  A  project  plan  must  accompany  each  DPP. 

This  project  information  is  critical  to  analysis  and  to  possible 
approval  by  the  WO  for  funding.  Be  clear  but  concise.  Items  I-V  are 
the  most  important.  Items  VI  and  VII  are  the  originating  office's 
general  ideas  and  estimates. 

I.  Title  -  Same  as  Form  1681-1  Date  —  Same  as  on  Form  1681—1. 

II.  Problem  or  Need  (what)  -  Reason  for  proposal. 

III.  Recommendations  and  Objectives  (what)  -  Originating  office's 

recommendations  on  what  to  do  about  problem  or  need,  and  the 
objectives  of  the  proposed  developmental  project. 

IV.  Description  -  General  description  of  project  (what). 

V.  Justification  (why)  -  Include  any  background,  benefits, 
rationale,  etc. 
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Form  1681—1 
(May  1981) 


UNITED  STATES 

DEPARTMENT  OF  THE  INTERIOR 
BUREAU  OF  LAND  MANAGEMENT 

DEVELOPMENT  PROJECT  PROPOSAL 

□  bureauwide  I  I  SPECIFIC 


NUMBER 


Assigned  (WO) 

Subactivity  (Field) 

Priority  (WO) 

Recommended  lead  office  (Field) 


Project  Title 

Type  of  project 

1  1  Information  Systems 

1  1  Renewable  Resources 

1  1  Energy  and  Minerals 

□  Lands  and  ROW 

1  1  Rec.  and  Environmental  Areas 

1  1  Policy  and  Budget 

1  1  Tech.  Services 

1  1  Administration 

Objective  statement  {summary) 


Justification  rfene/  summary) 


COSTS  SUMMARY 

ITEMS 

NUMBER 

AMOUNT 

Workmonth 

$ 

Procurement 

$ 

Equipment 

$ 

TOTAL 

$ 

I  I  Annual  Work  Plan 
Recommended  FY 


□ 


Initiated  at 

□  WO  □  SO 

□  sc  □  BIFC/OCS 

ommended  by  (signature) 


Approved  by  (signature) 


Annual  Work  Plan 
Supplement  to  FY 


[^3]  Continuing  Project 


%  completed  prior  to  this  FY 
%  to  be  completed  this  FY 


Office 


Division 


Originator’s  Name  and  Phone  No. 


Date 


Date 


Instructions  —  Originator  completes  and  submits  form  to  appropriate  WO  Office. 


GPO  831  -  193 
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Sect  ion 

1  (Cont . ) 

VI. 

Plan  for  Work  (How,  who.  where,  when)  -  Thic;  i  Mio 
initiator's  proposal  on  these  suggested  items.  The 
evaluation  process  will  determine  specific  needs  and 
recommendations . 

Procedures,  including  possible  alternatives. 

Proposed  location  of  work  and  recommended  lead  office. 

Should  SO/DO  handle,  etc? 

Personnel  ~  Types  and  amount  needed  including  number  and 
source  (office  or  staff)  of  WMs . 

Cost  and  funding  sources  (subactivities)  -  (1)  WMs  and 
costs,  (2)  procurement  items  and  costs,  (3)  equipment  items 
and  costs,  and  (4)  total  costs. 

Time  Schedule  -  Sequence  of  required  work,  completion  dates, 
number  of  fiscal  years  involved. 

Outputs  Produced  -  What  are  these? 

VII. 

Priority  -  Recommendations  on  urgency  of  work.  Insert  in 
current  year's  AWP  and  drop  other  work?  Start  next  FY,  etc? 

NOTE  - 

A  project  started  in  one  FY  and  carried  forward  into  another 
will  be  a  "Continuing  Project"  and  checked  as  such  on  Form 
1681-1.  After  the  first  year  only  Form  1681-1  will  be 
completed.  The  additional  project  description,  according  to 
the  above  format,  is  not  needed  unless  the  project  approach 
has  been  changed.  However,  refined  costs  estimates  will  be 
developed  each  year.  The  lead  office  conducting  the  project 
will  complete  the  form  for  the  subsequent  years  after 
project  initiation. 
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Section  2. 

Project  Team  Administration 

A.  Upon  receipt  of  an  approved  DPP,  the  Service  Center  Director 
(SCD)  will: 

1.  Assign  to  the  appropriate  Office  Chief  who  will: 

a.  Appoint  Project  Manager. 

b.  Complete  Software  Life  Cycle  Coordination  and 
Control  FormCs). 

c.  Select  project  team  analyst(s)  and/or 
programmer (s ) . 

d.  Define  brief  objectives  and  general  requirements 
in  writing  for  each  project  phase. 

e.  Develop  Requirements /Feasibility  study  as 
required. 

f.  Complete  Data  Systems  Request. 

g.  Prepare  initial  project  management  data  for  the 
Software  Life  Cycle  (PERT). 

B.  Walk-Through.  The  members  of  the  walk-through  team  will 
vary  in  accordance  with  the  material  being  reviewed.  The 
walk-through  is  chaired  by  the  Project  Coordinator  and 
conducted  by  the  individual  responsible  for  the  material. 

The  purpose  of  the  walk-through  is  to  determine  if  all 
requirements  of  the  users'  request  have  been  defined  and  to 
evaluate  the  project  definition  for  completeness  and 
accuracy.  Review  the  work  plan  for  the  Planning/Definition 
Phase  during  the  walk-through  and  make  adjustments  to  the 
plan  and  project  management  data  as  required. 

The  Initiation  Phase  must  be  approved  by  the  responsible 
individuals  and  management  before  the  Planning/Definition 
Phase  can  be  initialized. 


28 
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[ ]  OTHER _ 


SIGNATURE 
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INITIATION  PHASE 


DATA  SYSTEMS  REQUEST 


Sectiou  3. 

Data  Systems  Request 

A.  Purpose .  The  Data  Systems  Request  (DSR)  (Form  No.  )  is 
designed  for  ADP  Management  to  summarize  the  estimated  data 
processing  costs/work  months  and  advise  the  requestor  of  the 
action  that  will  be  taken. 

B.  Responsibility .  The  data  processing  project  team  is 
responsible  for  the  preparation  of  the  DSR  for  management 
approval . 

C.  DSR  Preparation  Instructions . 

1 .  ADP  Estimate  of  Costs  and  Work  Months  -  Preliminary . 

a.  This  section  will  include: 

1)  Data  processing  costs  for  implementing  and 
operating  a  new  system  or  changes. 

2)  Work  months  (173  hours)  for  implementing  a 
new  system  or  changes. 

2.  Comments .  ADP  management  will  include  any  comments 
relative  to  the  requested  system. 

3.  Action.  ADP  management  will  indicate  the  disposition 
of  the  Data  Systems  Request. 
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INITIATION  PHASE 


REQUIREMENTS/FEASIBILITY  STUDY 


Sectiou  4. 

Requirements/Feasibility  Study 

A.  Purpose.  The  laitiation  Phase  utilizes  a 

Requirements /Feasibility  Study,  as  required,  to  provide 
detailed  information  for  evaluation  of  the  economic  and 
technical  feasibility  of  a  proposed  system.  The 
Requirements/Feasibility  Study  further  clarifies  the  DPP  and 
is  required  for  all  requests  for  new  systems  or  changes  to 
existing  applications  where  the  estimated  development 
exceeds  six  work  years;  or  the  development  and/or 
operational  costs  exceed  $150,000. 

B-  Responsibility.  The  Requirements /Feasibility  Study  is 

divided  into  two  parts:  Requirements  and  Feasibility.  The 
requesting  organization  and/or  the  ADP  Project  Manager 
will  be  primarily  responsible  for  the  preparation  of  Part  1 
(Requirements),  while  Part  2  (Feasibility)  will  be  a  joint 
effort  of  the  requesting  organization  and  ADP  Management. 

1.  Requirements  -  Part  1. 

a.  Present  System. 

b.  Proposed  System. 

2.  Feasibility  -  Part  2. 

a.  Mandatory /Technical/Economic  Considerations. 

C.  Contents .  The  Requirements  are  written  by  the  requestor  to 
describe  the  requirements  of  a  proposed  system  in  his  own 
terms.  The  Feasibility  Study  elaborates  on  this  description 
and  presents  the  system  and  its  cost  in  more  detail  and  in  a 
more  technical  manner  by  the  systems  staff. 

D .  Requirements  Study  -  Present  System 

1.  State  the  title  of  the  PRESENT  System. 

2.  List  the  departments  and  sections  affected  by  the 
PRESENT  System  and  describe  their  involvemexit . 

3.  Prepare  a  functional  diagram  depicting  the  PRESENT 
System.  The  diagram  should  graphically  portray  the 
flow  of  information  within  the  user  organization  and/or 
data  processing.  Each  input,  output,  file,  and 
processing  activity  must  be  clearly  labeled  with  its 
name  and  volume.  This  diagram  must  also  depict  the 
relationship  between  the  PRESENT  System  and  external 
systems  with  which  it  interfaces. 
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INITIATION  PHASE 


REQUIREMENTS/FEASIBILITY  STUDY 


Section  4  (Coat.) 

4.  In  a  clear,  concise,  narrative  form,  describe  the 
PRESENT  System.  This  narrative  must; 

a.  Describe  the  functions  of  the  system. 

b.  Include  a  description  of  the  objectives  and  state 
how  these  objectives  are  met. 

c.  Specify  when,  where,  and  who  originates  input- 
The  narrative  must  specify  the  type,  contents, 
source(s),  frequency,  preparation,  transmission, 
control ,  and  balancing  criteria  of  the  input . 
(Examples  of  the  input  forms  and  input  contents 
are  to  be  attached.) 

d.  Describe  the  output.  The  narrative  must  specify 
the  type,  contents,  distribution,  frequency, 
control,  and  balancing  criteria  of  the  output. 
(Examples  of  output  forms  and  output  contents  are 
to  be  attached.) 

e.  Describe  the  files.  The  narrative  must  specify 
the  type,  contents,  source,  use,  sequence  or 
organization,  and  retention  of  the  files.  If  the 
file  volumes  fluctuate,  this  must  be  indicated. 

An  explanation  of  how  each  file  is  updated  with 
current  information,  or  how  outdated  data  is 
deleted,  must  be  included. 

f.  Itemize  and  describe  the  pertinent  tasks  which  are 
performed . 

5.  Describe  in  detail  all  manual  operations  that  are 
required . 

h.  Detail  all  machine  requirements. 

i.  Include  all  formula,  tables,  and  calculations 
being  used. 

j.  Include  a  description  of  all  handling  and  user 
controls  to  be  employed. 

k.  Describe  in  detail  how  the  PRESENT  System 
interfaces  with  existing  or  proposed  machines  or 
manual  systems. 

The  narrative  must  explain  why  a  Requirements  Study  is 
necessary.  It  must  detail  the  problems  anticipated 
with  the  current  system  and  the  new  goals  to  be 
achieved. 

E .  Requirements  Study  -  Proposed  System. 

1.  State  the  title  of  the  PROPOSED  System. 
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INITIATION  PHASE 


REpUIREMENTS/FEASIBILITY  STUDY 


Section  4  (Gout.) 

4.  List  the  departments  and  sections  affected  by  the 
PROPOSED  System  and  describe  their  involvement. 

3.  Prepare  a  functional  diagram  depicting  the  PROPOSED 
System.  This  diagram  should  graphically  portray  the 
flow  of  information  within  user  organization(s)  and/or 
data  processing.  Each  input,  output,  file,  and 
processing  activity  must  be  labeled  clearly  with  its 
name  and  volume.  This  diagram  must  also  depict  the 
ralationship  between  the  PROPOSED  System  and  the 
external  system(s)  with  which  it  interfaces. 

4.  In  a  clear  concise  narrative  form,  describe  the 
PROPOSED  System.  This  narrative  must; 

a.  Describe  the  functions. 

b.  Include  a  description  of  the  objectives  and  state 
how  these  objectives  are  to  be  met . 

c.  Specify  when,  where,  and  who  originates  input. 

The  narrative  should  specify  the  type,  contents, 
source(s),  frequency,  preparation,  transmission, 
control,  and  balancing  criteria  of  the  input. 
(Examples  of  the  input  forms  and  input  contents 
are  to  be  attached.) 

d.  Describe  the  output.  The  narrative  must  specify 
the  type,  contents,  distribution,  frequency, 
control,  and  balancing  criteria  of  the  output. 
(Examples  of  output  forms  and  output  contents  are 
to  be  attached). 

e.  Describe  the  files.  The  narrative  must  specify 
the  type,  contents,  source,  use,  sequence  or 
organization,  and  retention  of  the  files-  If  the 
file  volumes  fluctuate,  this  must  be  indicated. 

An  explantion  of  how  each  file  is  updated  with 
current  information,  and  how  outdated  data  is  to 
be  deleted,  must  be  included. 

f.  Itemize  and  describe  the  tasks  that  are  to  be 
performed . 

g.  Describe  in  detail  all  manual  operations  that  will 
be  required. 

h.  Detail  all  machine  requirements. 

i.  Include  all  formula,  cables,  and  calculations  to 
be  used  • 

j .  Include  a  description  of  all  handling  and  user 
controls  to  be  employed. 
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PROPOSED  SYSTEM  PRESENT  SYSTEM 


ECONOMIC  EVALUATION  SUMMARY 


DESCRIPTION 


NON-ADP  SALARY  AND  RELATED  COSTS 


NON-ADP  OTHER  COSTS 


ADP  PROCESSING  COSTS 


ADP  DEDICATED  EQUIPMENT  COSTS 


ADP  DATA  PREPARATION  COSTS 


OTHER  ADP  COSTS 


ANNUAL  COSTS 


Isf  YEAR 


2nd  YEAR 


3rd  YEAR 


COST  OF  PRESENT  SYSTEM 


NON-ADP  SALARY  AND  RELATED  COSTS 


NON-ADP  OTHER  COSTS 


NON-ADP  INCOME  (  )  (  )  (  > 


ADP  PROCESSING  COSTS 


ADP  DEDICATED  EQUIPMENT  COSTS 


ADP  DATA  PREPARATION  COSTS 


ADP  DEVELOPMENT  COSTS 


OTHER  ADP  COSTS 


COST  OF  PROPOSED  SYSTEM 


NET  SAVINGS  OR  INCREASED  INCOME 
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INITIATION  PHASE 


REQUIREMENTS/FEASIBILITY  STUDY 


Section  4  (Cont.) 

k.  Describe  in  detail  how  the  PROPOSED  System  will 
interface  with  existing  or  proposed  machine  or 
manual  systems. 

5.  Indicate  the  desired  implementation  schedule. 

6.  If  a  portion  or  subset  of  the  PROPOSED  System  can  be 
developed  and  implemented  ahead  of  the  entire  system, 
describe  it  and  relate  it  to  the  desired  implementation 
schedule  above . 

7.  Describe  the  life  span  of  the  PROPOSED  System  and 
relate  it  to  future  plans  or  other  system  developments. 

8.  Describe  alternatives  which  could  satisfy  most  or  all 
objectives  for  the  PROPOSED  System. 

9.  List  any  constraints  inherent  in  the  PROPOSED  System 
requirements  (limitations  upon  which  the  system  must 
depend,  such  as  equipment  required,  contracts  signed, 
and/or  availability  of  input). 

10.  Describe  all  special  equipment  or  services  (computers, 
remote  terminals,  communications  lines,  contract 
programming,  messengers,  etc.)  which  the  user  knows 
will  be  required  by  the  PROPOSED  System. 

11.  Specify  user  training  required  to  implement  or  operate 
the  PROPOSED  System. 

12.  Describe  all  one-time  conversions  of  user  files, 
numbering  systems,  etc.,  which  will  be  required  to 
implement  the  PROPOSED  System. 

F .  Feasibility  Study  -  Mandatory/Technical/Economic 

Considerations . 

1.  If  applicable,  explain  the  mandatory  reasons  for 
implementing  the  PROPOSED  System. 

2.  Describe  any  known  problems,  technical  or  otherwise, 
affecting  the  feasibility  of  the  PROPOSED  System. 

3.  The  Economic  Evaluation  Summary  (Form  No.  )  will  be 
used  as  a  broad  comparison  of  Present  System  costs  to 
the  PROPOSED  System  costs.  Describe  in  a  clear  and 
orderly  manner  the  economic  considerations  that  are 
applicable  to  the  PROPOSED  System.  These  economic 
considerations  must  be  divided  into  user  income  savings 
and/or  costs,  and  ADP  Management  costs  and/or  savings, 
with  both  being  summarized  to  produce  net 

income/ savings  and/or  costs. 
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INITIATION  PHASE 


Section 


RECjUIREMENTS/FEASIBILITY  STUDY 


(Coat • ) 

4.  The  user  must  include  in  these  economic  considerations 
the  required  resources  in  terms  of  personnel,  supplies, 
rentals,  equipment,  training,  etc.,  translated  to 
annual  dollar  expenditures.  The  user  must  also 
include,  in  the  economic  considerations,  any  savings  or 
additional  income  that  will  be  accrued  when  the 
PROPOSED  System  is  implemented. 

5.  The  ADP  Project  Manager  must  include  the  following  in 
these  economic  considerations  : 

a.  A  data  processing  flow  chart  illustrating  volumes- 

b.  Programming  manpower  requirements  to  program  the 
system,  and  the  related  costs  for  salary,  employee 
welfare,  stationery,  depreciation,  etc. 

c.  Software  purchases. 

d.  Machine  processing  requirements  and  the  annual 
cost  of  running  each  program. 

e.  Training  requirements  and  costs. 

f.  Annual  input  data  preparation  and  control  costs. 

g.  Annual  supply  and  equipment  requirements  and 
costs . 

6.  The  Project  Manager  will  specify  the  precise  data 
processing  costs  on  the  Job  Cost  Estimate  Form  (Form 

No.  _ ).  The  ADP  Project  Manager  will  summarize  the 

economic  considerations  on  this  form  in  order  to 
present  the  economic  effects  of  the  PROPOSED  System  in 
a  precise  manner. 
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INITIATION  PHASE 


COST  FACTORS 


Section  5. 
Cost  Factors 


Cost  is  a  major  element  in  determining  the  operating 
effectiveness  of  a  system.  Note,  however,  that  costly  systems 
are  not  necessarily  inefficient  ones.  A  system  must  not  be 
arbitrarily  discarded  or  rejected  because  it  is  expensive. 

Costly  systems  may  well  be  the  best  ones  if  they  are  achieving 
their  stated  objectives  with  minimum  errors. 

The  systems  analyst  must  provide  cost  factors  in  a  clear, 
concise,  and  standard  format.  Unusually  high  costs  should  be 
justified  and  explained. 

System  costs  should  be  projected  three  years  into  the  future. 

This  provides  a  measurement  of  how  efficiently  the  system  will 
handle  projected  growth  factors.  After  three  years,  cost 
estimates  tend  to  become  inaccurate  or  obsolete  because  of 
changes  within  systems. 

A.  Direct  System  Costs  -  These  include  labor  rate,  equipment 
expenses,  material,  supplies,  and  overhead. 

3.  Intangible  Savings  and/or  Costs  -  Any  costs  or  savings  that 
cannot  be  directly  attributed  to  a  system  are  included  in 
this  category.  They  can  be  used  to  provide  economic 
justification  of  a  system. 

Examples  of  intangible  benefits  associated  with  a  new  system 
include : 

1.  Improved  planning. 

2.  Stabilized  personnel  requirements. 

3.  Improved  inventory  control. 

4.  Improved  product  design. 

5.  Standardization. 

C.  Cost  of  Design  and  Implementation  -  Within  the  construction 
of  costs  for  the  proposed  system,  an  amount  for  each  design 
and  implementation  cost  must  be  included: 

1.  Detailed  systems  design  costs. 

2.  Programming  costs. 

3.  Cost  of  training  of  other  data  processing  personnel. 

4.  Conversion  and  system  testing  costs. 

5-  Cost  of  cut-over. 
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COST  FACTORS 


Section  5  (Coat.) 


6. 

7. 


Cost  of  retraining  Bureau  personnel . 
Cost  of  creatinj'  master  files. 


I 
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DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


INTRODUCTION 


Section  0. 
Introduction 


During  the  Planning/Definition  Stage  of  development,  the 
functional  and  data  requirements  for  the  software  are  determined. 

A.  Functional  Requirements.  The  Functional  Requirements  should 
provide  a  basis  for  the  mutual  understanding  between  users 
and  designers  of  the  initial  definition  of  the  software, 
including  the  requirements,  operating  environment,  and 
development  plan. 

B.  Data  Requirements .  The  Data  Requirements  should  provide  a 
data  description  and  technical  information  about  data 
collection  requirements. 


Walk-Through  Planning /Definition 


\ 


Flowchart 


System  Assumptions/ 
Constraints 


/ 


Integrated  System 
Environment  Chart 
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DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


PROJECT  TEAM  ADMINISTRATION 


Section  1. 

Project  Team  Administration. 

A.  Upon  completion  of  the  Initiation  Phase,  the  responsible 
project  team  member(s)  will  prepare: 

1.  Written  narrative  which  outlines  the  purpose,  scope, 
and  authorization  of  the  system. 

2.  Generalized  functional  description  of  the  new  system  or 
major  modification. 

3.  Functional  flowchart  which  graphically  portrays  the 
informational  flow  of  the  system. 

4.  Integrated  system  environment  chart. 

5.  List  of  system  assumptions  and  constraints. 

B.  Walk-Through .  The  members  of  the  walk-through  team  will 
vary  in  accordance  with  the  material  being  reviewed.  The 
walk-through  is  chaired  by  the  Project  Manager  and  conducted 
by  the  individual  responsible  for  the  material. 

The  purpose  of  the  walk-through  is  to  determine  if  all 
requirements  for  the  system  have  been  defined  and  to 
evaluate  the  system  definition  for  completeness  and 
accuracy.  Review  the  work  plan  for  the  Design/Specification 
Phase  during  the  walk-through  and  make  adjustments  to  the 
plan  and  project  management  data  as  required. 

The  Planning/Definition  Phase  must  be  approved  by  the 
responsible  individuals  and  management  before  the 
Design/Specification  Phase  can  be  initialized. 
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FORM  NO. 


DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


SYSTEM  NARRATIVE 


Section  2. 

System  Narrative 


A  system  narrative  must  be  written  to  outline  the  purpose  of  the 
system;  the  scope  in  terms  of  functional  and  organizational 
involvement;  and  authorization  of  the  system. 

This  narrative  would  be  used  to  communicate  outside  the  Division 
of  ADP  and  to  give  clear  intent  and  specific  boundaries  to  the 
subsequent  work  of  the  systems  analyst.  All  statements  must  be 
concise,  but  complete. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


SYSTEM  DESCRIPTION 


Section  3. 

System  Description 

The  system  description  will  consist  of  a  generalized  functional 
description  of  the  new  system  or  the  major  modification.  All 
inputs  and  outputs  of  the  system  must  be  described  in  narrative 
form,  including  interface  with  other  existing  or  planned  systems 
If  this  is  a  modification  or  an  extension  to  an  existing  system, 
it  should  be  explained  fully.  The  narrative  should  be  concise, 
orderly,  and  complete. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO  ). 
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DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


FUNCTIONAL  FLOW  CHART 


Section  4. 

Functional  Flow  Chart 


The  functional  flow  chart  will  graphically  portray  the 
informational  flow  of  the  system.  All  functions,  processes, 
procedures,  and  organizations  must  be  identified.  Large  scale 
systems,  or  significantly  complex  systems  (or  sub-systems),  may 
require  a  number  of  flow  charts  constructed  at  various  levels. 

The  information  reflected  on  the  top  level  flow  chart  should  be 
generalized  so  that  it  can  be  portrayed  on  a  single  sheet  and 
cross-referenced  to  subordinate  flow  charts  containing  the  system 
detail . 

FORMS:  SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


INTEGRATED  SYSTEM  ENVIRONMENT  CHART 


Section  5. 

Integrated  System  Environment  Chart 

The  integrated  system  environment  chart  for  the  subject  system, 
or  system  segment,  will  show  existing  or  proposed  interface  with 
all  other  manual  or  machine  systems.  The  subject  system  should 
be  emphasized  in  some  manner,  with  the  use  of  circles,  pointers, 
shading,  etc. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  PLANNING/DEFINITION 


SYSTEM  ASSUMPTIONS /CONSTRAINTS 


Section  6. 

System  Assumptions/Constraints 

A.  Assumptions .  Those  conditions  that  cannot  be  supported  by 
factual  information. 

B.  Constraints .  Circumstances  or  limitations  upon  which  the 
system  must  depend. 

Both  areas  may  have  a  definite  impact  on  the  system  from  the 
standpoint  of  design,  development,  implementation,  or  operation. 
Include  reference  to  schedule  constraints  upon  inputs  and 
outputs,  identifying  files/data  sets,  and/or  recurring  processing 
which  must  be  performed  either  prior  to,  or  as  a  result  of,  the 
operation  of  the  subject  system. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 
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INTRODUCTION 


Section  0. 
Introduction 


During  the  Design/Specifications  stage  of  development,  the  design 
alternatives,  specific  requirements,  and  functions  to  be 
performed  are  analyzed  and  a  design  is  specified.  The  design 
specifications  depict  how  a  new  system  and/or  modifications  to 
existing  systems  will  be  developed  and  implemented. 


Approval 


/ 

Walk-Through 

/ 

Glossary  of  Terms/ 
Abbreviat ions 


Modular  System 
Flow  Chart 


System  Input 
Requirements 


Modular  design  should  be  used  to  divide  the  problem  solution  into 
its  logical  parts  so  that  each  may  be  analyzed  and  then 
programmed  independently  on  a  structured  basis.  This  technique 
provides  for  considerable  efficiency  in  programming  time, 
computer  time,  and  maintenance  time  since  it  enables  complex 
problems  to  be  segmented  into  many  simple  sections.  A  structured 
program  reflects  the  program  organization  established  in  the 
system's  modular  flow  chart. 
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Section  0  (Cont . ) 

The  primary  design  criteria  of  modular  design  are,  ease  of 
understanding,  ease  of  program  modification,  and  standardization 
of  program  construction. 
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Section  1. 


Project  Team  Administration 


A. 


10 


11 


Upon  completion  of  the  Planning/Definition  Phase,  the 

responsible  project  team  member(s)  will: 

1.  Prepare  a  detailed  functional  description  of  the  new 
system  or  major  modification. 

2.  Prepare  a  detailed  functional  flow  chart  which 
graphically  protrays  the  informational  flow  of  the 
system. 

3.  Identify  and  define,  in  detail,  all  input  requirements 

4.  Identify  and  define,  in  detail,  all  output 
requirements . 

5.  Identify  and  define,  in  detail,  all  system  files /data 
sets  which  are  generated  and  used  internally  by  the 
system. 

6.  Select  file  designs  which  permit  efficient  processing 
of  information. 

7.  Describe  the  system  logic  requirements. 

8.  Identify  and  define,  in  detail,  the  control  procedures 
used  by  user  organizations  to  maintain  validity  of  the 
system.  Also,  describe  the  internal  processing 
controls  required  by  the  system. 

9.  Describe  and  document  the  computer  processing  logic  of 
the  system. 

Indicate  due  dates  for  system  implementation,  data 
input,  and  data  output. 

Provide  a  list  of  technical  terms,  words,  phrases,  and 
abbreviations  which  require  further  explanation  and 
definition . 


Walk-Through.  The  members  of  the  walk-through  team  will 
vary  in  accordance  with  the  material  being  reviewed.  The 
walk-through  is  chaired  by  the  Project  Manager  and  conducted 
by  the  individual  responsible  for  the  material. 

The  purpose  of  the  walk-through  is  to  determine  if  all 
design  requirements  for  the  system  have  been  defined  and  to 
evaluate  the  design  specifications  for  completeness  and 
accuracy.  Review  the  work  plan  for  the  Programming  Phase 
during  the  walk-through  and  make  adjustments  to  the  plan  and 
project  management  data  as  required. 
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Section 


DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 

PROJECT  TEAM  ADMINISTRATION 

(Cont . ) 

The  Design/Specifications  Phase  must  be  approved  by  the 
responsible  individuals  and  management  before  the 
Programming  Phase  can  be  initialized. 
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Section  2. 

Detailed  System  Description 

The  Detailed  System  Description  will  expand  the  general 
description  of  the  system  which  was  developed  in  the 
Planning/Definition  Phase,  and  will  consist  of  an  in-depth 
functional  narrative  of  the  new  system  or  the  major  modification 
All  inputs  and  outputs  of  the  system  must  be  described  in  detail 
including  interface  with  other  existing  or  planned  systems.  If 
this  is  a  modification  or  extension  to  an  existing  system,  it 
should  be  explained  fully.  The  narrative  should  be  concise, 
orderly,  and  complete. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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MODULAR  SYSTEM  FLOW  CHART 


Section  3. 

Modular  System  Flow  Chart 

The  Modular  System  Flow  Chart  will  expand  the  functional  flow 
chart  which  was  developed  in  the  Planning/Definition  Phase,  and 
will  graphically  portray  the  details  of  all  functions,  processes, 
procedures,  and  organizations  of  the  system.  Large-scale 
systems,  or  significantly  complex  systems  (or  sub-systems),  may 
require  a  number  of  flow  charts  constructed  at  various  levels. 

The  information  reflected  on  the  top  level  flow  chart  should  be 
generalized  so  that  it  can  be  portrayed  on  a  single  sheet  and 
cross-referenced  to  subordinate  flow  charts  containing  the  system 
detail . 

FORMS:  SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 
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SYSTEM  INPUT  REQUIREMENTS 


Section  4. 

System  Input  Requirements 

"Inputs"  are  defined  as:  (1)  source  documents  or  transmittals, 

(2)  punched  cards,  (3)  paper  tape,  (4)  remote  terminal  device 
messages,  and  (5)  data  sets/files  resident  on  magnetic  tape/disk, 
which  are  entered  as  input  to  the  system  from  an  interfacing 
system.  Data  Sets/Files  generated  and  utilized  internally  by  the 
system  are  described  in  Section  6  of  this  chapter. 

A.  Guidelines  for  Designing  Input. 

1.  Arrange  (sequence)  input  data  in  a  logical  pattern  to 
facilitate  the  user's  preparation  of  input  from  forms 
or  original  source. 

2.  Establish  complete  requirements  for  one-time  input  of 
all  data  required  to  sustain  all  computer  processes 
dependent  on  the  input . 

3.  Insure  that  data  required  for  an  input  action  does  not 
unnecessarily  duplicate  data  in  other  input  records. 

4.  Provide  clear  and  complete  instructions  for  gathering, 
preparing,  and  submitting  input  data  records  or  files. 

5.  Arrange  input  data  collection  to  insure  that  standard 
codes,  or  meaningful  mnemonics  if  possible,  are  used  to 
the  maximum  possible. 

6.  Design  input  requirements  so  that  personnel  preparing 
the  input  do  so  as  part  of  their  primary  work  function 
to  the  maximum  extent  possible. 

7.  Design  all  man/machine  dialogues  to  be  as  brief  and 
understandable  as  possible,  and  to  require  minimum 
interpretation  on  the  part  of  the  user. 

8.  Use  clear  text,  where  possible,  in  all  man/machine 
dialogues . 

B.  General  Description  of  System  Inputs .  Describe  each  input 
medium  as  to  its  purpose,  function,  and  relationship  to  the 
system.  Each  description  should  contain  sufficient  detail 
in  order  to  clearly  indicate  its  intended  application. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  _ ). 

C.  Preparation,  Control,  and  Transmission  Criteria.  Describe 
in  detail,  for  each  type  input,  the: 

1.  Organizational  responsibility. 

2.  Schedule. 
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3.  Manner  of  preparation. 

4.  Unique  encoding  criteria  or  instructions. 

5.  Pre-edits /controls . 

6.  Batching  -  cut  off  points /routing . 

7.  Transmission  of  source  documents. 

Documentation  for  inputs  entered  over  remote  terminals 
should  include  input  locations,  station  code  numbers,  and 
entry  schedules. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  _ ). 

D.  System  Components  Identification  ( Input ) .  Identify  and 
index  all  inputs  to  the  system,  which  are  generated  by  an 
interfacing  system.  Exclude  data  sets  or  files  generated 
and  utilized  internally  by  the  system. 

Instructions  for  the  completion  of  the  System  Components 
Identification  Form  (Form  No.  )  are: 

1 .  System  Name  -  Enter  the  official  name  assigned  to  the 
system. 

2.  Component  Class  -  Enter  the  word  INPUT  to  establish 
that  the  items  listed  are  inputs  to  the  system. 

3.  Item  Number  -  Enter  the  identification  number  of  the 
input,  which  will  uniquely  identify  the  specific  Source 
Document,  Transmittal,  Data  Set,  etc.,  indicated  in  the 
adjacent  title  block. 

Tit le  -  Enter  the  official  name  assigned  to  the 
respective  Source  Document,  Transmittal,  Data  Set,  etc. 
5.  Reference  Page  -  Enter  the  subsequent  page  numbers, 

wherein  further  detail  regarding  the  specific  input  is 
indicated;  i.e..  Input  Requirements  Forms  (Form  No.  ). 

E.  Input  Requirements.  Identify  and  describe  each  type  of 
input  listed  on  the  System  Components  Identification  Form, 
The  Input  Requirements  Form  will  be  used  to  provide  the 
pertinent  information  regarding  each  input. 

Instructions  for  the  completion  of  the  Input  Requirements 
Form  (Form  No.  )  are: 


53 


DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


SYSTEM  INPUT  REQUIREMENTS 


Section  4  (Cont .  ) 

1-  System  Name  -  Enter  the  official  name  of  the  system. 

This  name  must  correspond  to  the  system  name  previously 
assigned  on  the  System  Components  Identification  Form. 

2.  Item  Number  -  Enter  the  identification  number  that  has 
been  assigned  to  the  specific  input.  This  number  must 
correspond  to  the  item  number  previously  assigned  on 
the  System  Components  Identification  Form. 

3.  Input  Title  -  Enter  the  assigned  title  of  the  subject 
Source  Document,  Transmittal,  Data  Set,  etc.  This 
identifying  name  must  correspond  to  the  title 
previously  indicated  on  the  System  Components 
Identification  Form. 

4.  Medium  -  Indicate  the  type  of  vehicle/mode  applicable 
to  subject  input;  i.e.,  card,  tape,  terminal,  etc. 

5.  Source  Document  Name  -  Enter  the  name  of  the 
originating  source  document. 

6.  Source  -  Enter  the  originating  activity,  abbreviated 
name,  or  number  that  has  been  assigned  responsibility 
for  providing  subject  information. 

7.  Length  -  Indicate  whether  the  informational 
requirements,  as  specified  herein,  are  Variable  or 
Fixed. 

8.  Frequency  -  Enter  the  input  frequency  established  as 
required  for  the  input;  i.e.,  Daily,  Weekly,  Monthly, 
etc  . 

9.  Estimated  Volume  -  Enter  the  number  of  Source 
Documents,  Transmittals,  and/or  Data  Sets  that  may  be 
expected,  based  on  the  aforementioned  frequency. 

10.  Machine  Type  -  Enter  the  appropriate  identification 
number  of  the  input  generating  device  for  the  subject 
information;  i.e.,  029,  129,  1810,  CMC1800,  CRT,  etc. 

11.  Verify  -  Indicate  whether  or  not  verification  of  the 
informational  requirement  is  essential. 

12.  General  Instructions  -  Enter  any  additional 
instructions  or  criteria  required;  i.e.,  sequencing, 
unique  keypunch  or  terminal  operator  instructions, 
disposition  and  control  of  source  documents,  procedural 
references,  etc. 

13.  Card/ Record/Mess age /Types  -  The  following  information 
will  be  provided  for  each  input  Record,  Message,  or 
Data  Set. 
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1^-  Item  Number  -  This  number  is  an  extension  of  the  basic 
item  number  provided  in  the  upper  right  hand  corner  of 
this  form.  This  item  number  is  developed  by  adding  a 
numeric  designation,  in  ascending  order,  to  the  basic 
item  number. 

15.  Record  Name  -  Enter  the  name  that  will  be  used  to 

identify  the  specific  Record,  Message,  and  Data  Set 
input . 

16 •  Special  Instructions  ~  Enter  the  reference  page  number 
of  subsequent  pages  wherein  further  details  concerning 
the  input  record,  message,  and/or  data  set  are 
specified.  Only  those  pages  indicating  the  next  lower 
level  of  detail  should  be  referenced  using  the 
Record/Message  Format  Form  (Form  No.  ). 

F.  Record/Message  Format  (Input).  Describe  in  detail  each  type 
of  input  listed  in  the  "Cards /Record/Message  Types"  area  of 
the  Input  Requirements  Form.  The  Record/Message  Format  Form 
will  be  used  to  provide  the  detailed  format  for  each  input. 

Instructions  for  the  completion  of  the  Record/Message  Format 
Form  (Form  No.  )  are: 

1-  System  Name  -  Enter  the  official  name  of  the  system. 

This  name  must  correspond  to  the  system  name  previou  sly 
assigned  on  the  Input  Requirements  Form. 

2.  Component  Class  -  Enter  the  word  INPUT  to  indicate  that 
listed  details  apply  to  input  requirements. 

3.  Item  Number  -  Enter  the  item  number  assigned  to 
identify  this  specific  input.  This  number  must 
correspond  to  the  item  number  previously  assigned  on 
the  Input  Requirements  Form. 

4.  Name  -  Enter  the  assigned  Card,  Record,  or  Message  name 
corresponding  to  the  record  name  previously  assigned  to 
the  input  on  the  Input  Requirements  Form. 

5.  Length  -  Enter  the  maximum  number  of  characters  that 
may  be  contained  within  this  Card,  Record,  or  Message. 
Any  special  and/or  unique  conditions  should  be 
indicated  in  the  requirements  blocks. 

6.  Reference  Page  -  Enter  the  page  number  of  the  sample 
Input  Document. 
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7.  Item  Number  -  Enter  a  numeric  designation  (in  ascending 
order)  that  will  identify  each  specific  data  element 
(field  name).  This  item  number  is  a  further  extension 
of  the  item  number  described  above. 

8.  Field  Name  -  Enter  the  word,  phrase,  or  term  used  to 
identify  the  data  element. 

9.  Format  -  Enter  the  specified  characteristics  that  have 
been  established  for  the  data  element.  For  purposes  of 
this  specification,  indicate  whether  the  contents  of 
the  data  element  field  are  alpha,  numeric,  or 
alpha-numeric;  i.e.,  A,  N,  A/N.  Also,  indicate  the 
maximum  number  of  characters  (in  parentheses)  that  may 
be  specified  for  this  data  element  field;  i.e.,  (1), 
(15),  (100),  etc. 

10.  From/To  -  Enter  the  columnar  positions  allocated, 
assigned,  or  required  by  the  data  element  field.  The 
From/To  requirements,  which  denote  the  size  of  the 
input  data  element  field,  must  be  compatible  with  the 
contents  indicated  in  the  format  block  above. 

11.  Requirements  -  Describe  any  peculiarities,  unique 
conditions,  circumstances,  instructions,  criteria, 
relationships,  and  references  regarding  the  data 
element . 

G.  Input  Samples.  Compile  a  sample  of  each  Source  Document, 
Transmittal,  or  Card,  which  generates  input  for  system 
entry.  Each  sample  should  be  an  actual  document  or  a  copy 
of  an  actual  document. 

Inputs  such  as  magnetic  tape/disk,  paper  tape,  and  on-line 
transmissions  must  also  be  shown  here.  It  is  suggested  that 
representative  data  be  inserted  for  each  input. 

H.  Request  for  Key  Entry  Services.  Complete  the  Request  for 
Key  Entry  Services  Form  (Form  No.  ),  and  forward  to  the 
individual  responsible  for  the  Key  Entry  Service  for  review 
and  approval . 
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System  Output  Requirements 

Identify  and  define,  in  detail,  all  output  requirements  for  the 
system  or  major  modification.  "Outputs"  are  defined  as:  (1) 
printed  reports,  (2)  punched  cards,  (3)  visual  display,  (4)  audio 
responses,  (5)  magnetic  tape/disk,  and  (6)  paper  tape  which 
support  an  interfacing  system.  Data  sets/files  generated  and 
utilized  internal ly  by  the  system  are  described  in  Section  6  of 
this  Chapter. 

A.  Guidelines  for  Designing  Output. 

1.  Design  output  products  for  ease  of  use  - 

a.  Output  products  should  be  clearly  identified. 

b.  Plotter  products  should  be  clearly  identified. 

c.  Products  on  hard  copy  should  have  space  for  notes, 
marks,  etc.,  as  required  by  the  user. 

d.  Tabular  reports  should  have  clearly  defined 
columns  and  rows.  If  figures  and  crossfooting  are 
involved,  they  should  be  easily  followed. 

e.  CRT  displays  should  be  designed  to  be  readily 
identifiable,  readable,  and  accessible. 

2.  Design  the  contents  of  output  products  to  be 
selfstanding  to  the  maximum  extent  with  minimum 
reliance  on  codes.  If  codes  must  be  used,  they  should 
be  standard  codes  for  standard  data  elements. 

3.  Plan  the  preparation  of  output  products  to  clearly  show 
the  dates  prepared  and  the  date(s)  or  period(s)  for 
which  the  contents  are  valid,  or  the  date  of  the 
file(s)  from  which  the  data  was  taken. 

4.  Review  for  content  all  reports,  graphs,  and  displays  to 
avoid  unnecessary  duplication  with  other  reports  or 
displays . 

5.  Design  products  containing  related  elements  of 
information  so  that  the  elements  have  a  logical 
grouping  sequence. 

6.  Develop  outputs  which  are  to  be  machine-used  in 
sequences,  formats,  codes,  and  character  sets  which 
facilitate  subsequent  processing  of  the  data. 

7.  Consider  the  output /medium/product ,  the  mode  of 
transmission,  and  the  user's  purposes.  Apply  logic  and 
consult  with  the  user  in  designing  what  he  will  receive 
to  do  his  job. 
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8.  When  an  individual  is  interacting  with  a  file,  such  as 
in  the  payroll  area,  the  CRT  displays  should  provide 
legibility  and  ease  of  interaction,  display,  input,  and 
correction . 

9.  Design  error/reject  messages  to  inform  the  user  of 
correction  procedures  insofar  as  possible. 

B.  General  Description  of  System  Outputs.  Describe  each  output 
product  as  to  its  purpose,  function,  and  its  relationship  to 
other  output  products  or  to  other  interfacing  systems  which 
it  supports.  Each  description  should  contain  sufficient 
detail  that  will  clearly  indicate  the  intended  application. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 


C.  Output  Control  and  Distribution.  Describe,  in  detail,  for 
each  type  output,  the: 

1.  Control  Requirements. 

2.  Frequency. 

3.  Form  Paper. 

4.  Distribution. 

5.  Forwarding  Instructions. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  _ ). 

D.  System  Components  Identification  (Output ) .  Identify  all 
system  outputs  which  support  an  interfacing  system.  Exclude 
data  sets/files  generated  and  utilized  internally  by  the 
system. 

Instructions  for  completing  the  System  Components 
Identification  Form  (FORM  NO.  _ )  are: 

1.  System  Name  -  Enter  the  official  name  assigned  to  the 
system. 

2.  Component  Class  -  Enter  the  word  OUTPUT  to  indicate 
that  items  listed  are  system  outputs. 

3.  Item  Number  -  Enter  the  identification  number  of  the 
output,  which  will  uniquely  identify  the  specific 
report,  card,  tape,  etc.,  indicated  in  the  adjacent 
title  block. 

4.  Tit le  -  Enter  the  official  name  assigned  to  the 
specific  report,  card,  tape,  etc. 
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5.  Reference  Page  -  Enter  the  subsequent  page  numbers 

wherein  further  details  regarding  this  specific  output 
are  described.  Only  those  page(s)  concerned  with  the 
next  lower  level  of  detail  should  be  referenced:  i.e., 
Output  Requirements  form.  (FORM  NO.  _ ). 

E.  Output  Requirements.  Identify  and  describe  each  type  output 

listed  on  the  System  Components  Identification  Form.  The 

Output  Requirements  Form  will  be  used  to  provide  the 

pertinent  information  regarding  each  output . 

Instructions  for  the  completion  of  the  Output  Requirements 

Form  (FORM  NO.  _ )  are: 

1.  System  Name  -  Enter  the  official  name  of  the  system. 
This  name  must  correspond  to  the  system  name  previously 
assigned  on  the  System  Components  Identification  Form. 

2.  Item  Number  -  Enter  the  identification  number  assigned 
to  the  specific  output.  This  number  must  correspond  to 
the  item  number  previously  assigned  on  the  System 
Components  Identification  Form. 

3.  Output  Title  -  Enter  the  assigned  title  of  the  subject 
report,  card,  message,  response,  etc.  This  identifying 
name  must  correspond  to  the  title  previously  indicated 
on  the  System  Components  Identification  Form. 

4.  Medium  -  Indicate  the  type  of  vehicle/mode  applicable 
to  subject  output;  i.e.,  printed  report,  card,  visual 
display,  audio  response,  etc. 

5.  Form  Type  -  Enter  the  form  requirements  for  the  output; 
i.e.,  color,  weight,  Xerox,  etc. 

6.  ForTn  Size  -  Enter  the  dimensional  requirements  for  the 
output;  ie . ,  8  x  11,  11  x  17,  etc. 

7.  Number  of  Parts  -  Enter  the  number  of  copies  that  are 
to  be  generated  by  the  system/ program. 

8.  Lines/Inch  -  Enter  the  lines  per  inch  requirements  of 
the  output,  if  applicable. 

9.  Frequency  -  Enter  the  frequency  or  time  interval  in 
which  output  will  be  generated;  i.e.,  daily,  weekly, 
monthly,  etc. 

10.  Record/Message  Types  -  The  following  information  will 
be  provided  for  each  output  record  or  message.  Note : 

It  is  not  necessary  to  include  descriptions  of  literals 
which  appear  in  printed  report  headings.  These  may  be 
obtained  from  the  form  layouts. 
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12.  Item  Number  -  This  number  is  an  extension  of  the  basic 

item  number  provided  in  the  upper  right  hand  corner  of 

this  form.  This  item  number  is  developed  by  adding  a 

numeric  designator  in  ascending  order,  to  the  basic 
item  number. 

13.  Pages  Where  Present  -  Enter  the  affected  pages  of  the 
output  in  which  the  record  or  message  will  appear; 
i.e.,  All,  1,  2,  etc . 

1'^  •  Line  Number  When  Present  ~  Enter  the  line  numbers  of 
the  page  in  which  the  record  or  message  will  appear; 
i.e.,  2,  2  and  4,  2-54,  etc. 

15.  Record  Name  -  Enter  the  name  assigned  to  identify  the 
record  or  message;  i.e..  Report  Title  Line,  Report 
Header,  Detail  (1),  etc. 

16.  Lines  Skipped  Before  Print  -  Enter  the  applicable 
number  of  lines  to  be  skipped  from  the  last  printed 
line.  Leave  blank  if  not  applicable,  or  if  skipping  of 
lines  is  not  required. 

17.  Reference  Page  -  Enter  the  reference  page  number  of 

subsequent  pages  in  which  further  details  concerning 
the  record  or  message  are  described.  Only  those  pages 
indicating  the  next  lower  level  of  detail  should  be 
referenced  using  the  Record/Message  Format  Form  (FORM 
NO.  _ ). 

18.  Report  Sequence  and  Control  -  The  following  sequence 
and  control  type  information  should  be  provided  for 
each  identified  output. 

19.  Field  Name  -  Enter  in  descending  order  (major  to  minor) 
the  data  elements  used  in  sequencing  the  applicable 
output . 

20.  Control  Actions  ~  Enter  all  unique  or  special  control 
actions/conditions  that  affect  or  pertain  to  the 
output . 

21 .  General  Instructions  -  Enter  any  additional 
instructions  that  should  be  considered  or  required  by 
the  system  output. 

F.  Record/Message  Format  (Output ) .  Describe,  in  detail,  each 
type  of  output  listed  in  the  "Record/Message  Types"  area  of 
the  Output  Requirements  Form.  The  Record/Message  Format 
Form  will  be  used  to  provide  the  detailed  format  for  each 
output . 
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Instructions  for  the  completion  of  the  Record/Message  Format 

Form  (FORM  NO.  _ )  are: 

1.  System  Name  -  Enter  the  official  name  of  the  system. 
This  name  must  correspond  to  the  system  name  previously 
assigned  on  the  Output  Requirements  Form. 

2.  Component  Class  -  Enter  the  word  OUTPUT  to  indicate 
that  listed  items  apply  to  some  output  requirement . 

3.  Item  Number  -  Enter  the  item  number  assigned  to 
identify  this  specific  output.  This  number  must 
correspond  to  the  item  number  previously  assigned  on 
the  Output  Requirements  Form. 

4.  Name  -  Enter  the  assigned  record  or  message  name 
corresponding  to  the  record  name  previously  assigned  on 
the  Output  Requirements  Form. 

5.  Length  -  Enter  the  maximum  number  of  characters  that 
will  be  required  and  generated  for  this  record  or 
message.  Any  special  or  unique  condition  should  be 
indicated  in  the  requirements  blocks. 

6.  Reference  Page  -  Enter  the  page  number  of  the  sample 
Output  Document. 

7.  Item  Number  -  Enter  a  numeric  designator  (in  ascending 
order)  to  identify  and  distinguish  each  specific  data 
element  (field  name).  This  item  number  is  a  further 
extension  of  the  item  number  described  above. 

8.  Field  Name  -  Enter  the  word,  phrase,  or  term  assigned 
to  identify  the  data  element. 

9.  Format  -  Enter  the  specific  characteristics  that  have 
been  established  for  the  data  element.  For  purposes  of 
this  specification,  entries  will  be  noted  as  alpha, 
numeric,  or  alphanumeric,  i.e.,  A,  N,  A/N.  Also 
indicate  the  maximum  number  of  characters,  in 
parentheses,  that  may  be  used  for  the  data  element 
field;  i.e.,  (1),  (15),  (100),  etc. 

10.  From/To  -  Enter  the  columnar  positions  allocated, 
assigned,  or  required  by  the  data  element  field.  The 
From/To  requirement,  which  denotes  the  size  of  the 
output  data  element  field,  must  be  compatible  with  the 
contents  indicated  in  the  format  block  above. 

11.  Requirements  -  Describe  any  peculiarities,  unique 
conditions,  circumstances,  instructions,  criteria, 
relationships,  or  references  regarding  the  data 
element . 
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G.  Report  Page  Heading.  Unless  system  requirements  specify 
otherwise,  all  reports  produced  that  are  printed  on  other 
than  preprinted  forms  will  display  the  following  page 
heading  information: 

1 .  Bureau  Name  -  The  Bureau  receiving  the  report . 

a.  Division  Name  -  The  Division  within  the  Bureau 
that  utilizes  the  report. 

b.  Report  Identification  -  The  report  ID  that 
uniquely  identifies  the  report  (program  ID,  etc.). 

2.  Report  Title  -  The  purpose  or  function  of  the  report. 

3.  Page  Number  -  The  report  page  number  in  ascending 
sequence. 

4.  Run  Date  (MMDDYY)  -  The  date  report  was  produced  on  the 
computer . 

5.  Run  Time  (HHMM)  -  The  time  of  day  report  was  produced 
on  the  computer. 

6.  Report  Day  (MM/DD/YY)  -  The  cutoff,  month  end,  payroll 
period,  etc.,  date  that  is  associated  with  the  report. 

H .  Report  Design  Considerations. 

1.  Cost  and  Time  Savings.  When  designing  large  reports, 
especially  those  for  only  occasional  references,  every 
effort  should  be  made  to  conserve  print  time,  paper, 
and  storage.  One  might  consider  these  possibilities: 


a . 

Can 

it  be  single  spaced? 

b. 

Can 

fewer  print  lines  per  report 

entry  be  used? 

c . 

Can 

it  be  printed  two-up,  three- 

up? 

d. 

Would  microfilm  or  fiche  be  more 

practical? 

e , 

Would  copies  be  best  for: 

1) 

Customer  use? 

2) 

Cost  justification? 

3) 

Operation  considerations? 

2 .  Custom  Forms.  Reports  to  be  printed  on  preprinted 
forms  must  contain  format  records  to  assist  the 
operator  in  aligning  the  form. 

3.  Notification  of  "No  Report".  When  any  regularly 
scheduled  report  is  not  generated  on  a  given  processing 
cycle,  the  report  program  should  cause  one  page  with 
headers  to  be  printed  with  the  message  "no  report  this 
cycle" . 


i 
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4.  Microfilm  and  Fiche.  For  many  high  volume 

applications,  microfilm  or  fiche  can  be  an  efficient 
output  medium.  The  designer  must  consider  storage  and 
retention  requirements,  type  and  frequency  of 
reference,  requirement  and  availability  of  various 
types  of  viewing  and  retrieval  equipment,  indexing 
methods,  reduction  factors,  etc. 

The  beginning  and  ending  control  numbers  on  a  reel  of 
microfilm  may  be  adequate  access  information  for  some 
applications  while  others  will  require  rather 
sophisticated  indexing  methods  and  specialized 
retrieval  equipment,  possibly  with  hard  copy 
capability.  A  header  which  is  visible  in  the  storage 
folder  is  recommended  for  all  microfiche.  This  header 
should  show  at  least  the  beginning  control  number  on 
that  fiche  and  date  or  cycle  number.  One  frame  of  the 
fiche  might  also  be  used  as  the  matrix  index  for  the 
contents  of  that  fiche. 

Although  frequently  requested  by  users,  the  expense  of 
producing  a  report  and  film  or  fiche  of  that  report  can 
seldom  be  justified.  In  those  cases  where  both  are 
required,  it  may  be  cheaper  to  film  the  printed  output 
if  the  print  tape  cannot  be  used  for  both  purposes  and 
a  separate  microfilm  tape  would  have  to  be  produced. 

Utilization  of  a  form  flash  can  often  make  film  or 
fiche  easier  to  use,  especially  when  a  great  deal  of 
information  is  being  recorded  for  each  entry.  A  "form 
flash"  is  a  custom  form  image  either  on  a  glass  or  on 
film,  reduced  by  the  same  factors  as  the  microfilm. 

This  image  is  superimposed  on  the  microfilm.  A  form 
flash  is  recommended  if  hard  copy  of  certain  frames 
will  be  sent  to  outside  sources. 

Reports  which  are  suitable  for  representation  as  two-up 
on  film  need  not  necessarily  be  generated  as  two-up  on 
tape.  Each  page  or  document  can  be  individually 
generated  with  a  frame  advance  as  the  control  character 
for  the  last  record  of  the  page  or  document  if  a 
hardware  feature  is  available  on  the  microfilm  unit 
which  can  be  used  to  record  two  images  per  frame .  A 
single  image  form  flash  can  be  used. 
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I.  Output  Samples.  Compile  samples  of  the  output  to  be 

generated  by  the  system;  i.e.,  printed  reports,  punched 
cards,  magnetic  tape/disk,  paper  tape,  visual  displays, 
audio  responses,  etc. 

Include  a  sample  of  each  preprinted  form  used  in  the  system. 
If  new  forms  are  required  for  the  new  system,  include  a 
sample  of  each  form,  drawn  and  lettered  to  scale. 

Underscore  or  otherwise  indicate  items  of  text  that  are 
preprinted  to  distinguish  them  from  the  computer  data 
output.  Use  sample  data  on  all  forms. 

Output  that  is  not  printed  on  preprinted  forms  must  be  drawn 
on  the  Report  Layout  Form  (DSC  1265-;i!')i;^indi eating  the  print 
format  required.  Include  sample  data  on  the  report. 

Prepare  typewritten  samples  of  Terminal 

Typewriter/Printer/CRT  output.  Indicate  the  maximum  text 
width  in  characters,  and  text  depth  in  lines.  Use  forms  or 
facsimile  copies,  if  applicable. 

Prepare  layouts  of  interfacing  tape/disk  supporting  other 
3  y  3 1 6tn3  . 

For  Datacom  applications  refer  to  "Data  Commune iat ions " 
section  of  this  manual. 
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System  Files/Data  Sets. 


Identify  and  define,  in  detail,  all  Files/Data  Sets  resident  on 
magnetic  tape/disk,  which  are  generated  and  utilized  internally 
by  the  system. 

A.  General  Description  of  Files/Data  Sets.  Describe  each 
internal  output  file/data  set  with  respect  to  purpose, 
function,  and  relationship  to  other  system  output.  Each 
description  should  contain  sufficient  detail  so  that  it 
clearly  indicates  the  intended  application. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  _ ). 

B.  Files/Data  Sets  Identification.  Identify  and  index  all 
files  and  data  sets  generated  for  internal  use  by  the 
system. 

Instructions  for  the  completion  of  the  System  Components 
Identification  Form  (FORM  NO.  _ )  are: 

1-  System  Name  -  Enter  the  official  name  assigned  to  the 
system. 

2.  Component  Class  -  Enter  the  words  SYSTEM  FILES  to 
indicate  that  these  files/data  sets  are  internal  to  the 
system. 

3.  Item  Number  -  Enter  the  system  identification  number  of 
the  file/data  set. 

4.  Tit le  -  Enter  the  official  name  assigned  to  the  file, 
data  set,  etc. 

5.  Reference  Page  -  Enter  the  subsequent  page  numbers 

where  further  detail  regarding  the  specific  internal 
output  is  provided;  i.e.,  Record/Message  Format  Form 
( FORM  NO .  )  . 


C.  Record/Message  Format  (Internal).  Describe  in  detail  each 
type  output  listed  on  the  System  Components  Identification 
Form.  The  Record/Message  Format  Form  will  be  used  to 
provide  the  detailed  format  for  each  output. 

Instructions  for  the  completion  of  the  Record/Message  Format 
Form  (FORM  NO.  )  are: 
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1-  System  Name  -  Enter  the  official  name  of  the  system. 

This  name  must  correspond  to  the  system  name  previously 
assigned  on  the  System  Components  Identification  Form. 

2.  Component  Class  -  Enter  the  words  SYSTEM  FILES  to 
indicate  that  listed  details  apply  to  an  internal 
file/data  set. 

3.  Item  Number  -  Enter  the  item  number  assigned  to 
identify  this  specific  output.  This  number  must 
correspond  to  the  item  number  previously  assigned  on 
the  System  Components  Identification  Form. 

4.  Name  -  Enter  the  assigned  file/data  set  name  previously 
assigned  on  the  System  Components  Identification  Form. 
Also  enter,  in  parenthesis,  the  name  of  the  record  or 
message  within  the  file/data  set  that  is  described  in 
detail . 

5.  Length  -  Enter  the  maximum  number  of  characters  that 
will  be  required  and  generated  for  this  record  or 
message.  Any  special  and/or  unique  condition  should  be 
indicated  in  the  requirements  blocks. 

6.  Reference  Page  -  Provide  cross-references  to  subsequent 
pages  which  contain  this  specific  output  Record  or  Card 
Layout  Form. 

a.  For  each  type  output,  its  Record  or  Card  Layout 
Form  should  immediately  follow  the  respective 
Record/Message  Format  Form. 

7.  Item  Number  -  Enter  a  numeric  designator  (in  ascending 
order)  that  will  identify  each  specific  data  element 
(field  name)  within  the  record  or  message.  This  item 
number  is  a  further  extension  of  the  item  number 
described  in  the  paragraph  above. 

8.  Field  Name  -  Enter  the  word,  phrase,  or  term  used  to 
identify  the  data  element. 

9.  Format  -  Enter  the  specific  characteristics  that  have 
been  established  for  the  data  element.  For  purposes  of 
this  specification,  entries  will  be  noted  as  alpha, 
numeric,  or  alphanumeric,  i.e..  A,  N,  or  A/N.  Also 
indicate  the  maximum  number  of  characters,  in 
parentheses,  contained  in  the  data  element  field;  i.e., 
(1),  (15),  (100),  etc. 

10.  From/To  -  Enter  the  columnar  positions  assigned  to  the 
data  element  field.  The  From/To  span  must  be 
compatible  with  the  contents  indicated  in  the  adjacent 
format  block. 
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11 •  Requirements  -  Describe  any  peculiarities,  unique 

conditions,  relationships,  criteria,  etc.,  of  the  data 
element . 

Prepare,  for  each  record/message  format  the  appropriate 
record  layout. 
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File  Design 

A.  Introduction .  A  file  is  a  logical  grouping  of  data  elements 
in  a  physical  medium  which  provides  for  efficient  processing 
of  information.  Any  system  can  operate  only  as  efficiently 
as  the  file  construction  permits.  It  is  therefore  essential 
to  maintain  a  controlled  sequence  of  procedures  during  file 
design.  The  thorough  research  accomplished  through  such 
procedures  will  result  in  informed  decisions  during  the 
selection  phase. 

While  the  use  of  controlled  design  procedures  requires  more 
effort  than  haphazard  matching  and  selection,  the  benefits 
will  be  evident  in: 

1.  Less  storage  space  required. 

2.  More  timely  inquiry  response. 

3.  Faster  access. 

4.  Easier  maintenance. 

5.  Better  mobility. 

6.  Less  data  redundancy. 

7.  Improved  communications  with  the  user. 

Since  the  success  or  failure  of  any  system  is  measured  in 
these  terms,  as  well  as  whether  or  not  it  produces  the 
desired  output,  it  is  necessary  to  design  the  files  by  a 
process  that  considers  all  of  these  factors. 

1.  Requirements  Definition.  The  first  step  is  the 

definition  of  the  requirements  for  the  system.  This  is 
done  by  considering  the  following: 

a.  The  input  requirements  should  be  thoroughly 
analyzed  and  classified. 

b.  The  relationships  of  all  data  and  data  elements 
must  be  established,  including  data  dependencies 
and  validation  criteria. 

c.  Security  requirements  must  be  identified. 

d.  The  processing  needs  must  be  detailed  to  include 
the  following: 

1 )  Volume . 

2)  Frequency. 

3)  File  percentages  to  be  accessed  at  only  one 
point  in  time  or  during  any  one  update. 

4)  Sequence  of  input. 

5)  Inquiry  and  response  requirements. 

6)  Turnaround  times. 
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e.  Relationships  and  dependencies  between  data 
elements  must  be  determined  and  documented. 

f.  Output  requirements  must  be  defined  and  described. 
These  should  consider: 

1)  Volume. 

2)  Frequency. 

3)  Format. 

4)  Sequence. 

2.  Data  Definition  The  next  step  is  to  define  all  aspects 
of  the  data.  Each  data  element  should  be  thoroughly 
understood  and  documented.  This  documentation  should 
include  the  following: 

a.  A  full  description  of  the  data  elements. 

b.  Details  regarding  the  use  and  purpose  of  the  data. 
This  should  show  whether  the  data  is  used  in  a 
calculation,  is  a  form  of  identification,  is  a  key 
element  used  for  inquiry,  or  if  the  data  is  used 
in  conjunction  with  other  data  as  a  grouping 
device . 

c.  The  originator  of  each  data  element  must  be 
determined  and  documented. 

d.  The  ultimate  destination  of  the  data  elements  must 
be  determined  and  documented. 

3.  Other  Design  Considerations.  When  all  information 
regarding  the  data  and  requirements  has  been  gathered 
and  documented,  it  is  then  necessary  to  consider  other 
factors  that  will  play  a  part  in  the  file  design. 

These  factors  are  generally  more  intangible  than  the 
previously  discussed  items  but  are  important  to  the 
success  of  the  system. 

a.  Flexibility.  The  possible  growth  of  the  file  both 
in  relation  to  volume  and  the  addition  of  new 
elements  must  be  established. 

b.  Ease  of  maintenance.  Any  file  that  requires 
maintenance  as  opposed  to  remaining  in  a  static 
condition  should  have  ease  of  maintenance  as  a 
consideration. 
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c.  Transportability.  Unless  there  are  essential 
overriding  considerations,  all  files  should  be 
provided  with  maximum  transportability.  Major 
systems  are  expensive  both  in  monetary  value  and 
effort.  With  this  in  mind,  it  should  be 
remembered  that  a  good  system  should  outlive  the 
hardware  on  which  it  is  initially  installed,  and 
should  be  readily  adaptable  to  new  equipment. 

d .  Hardware/Software  Restrictions.  As  far  as 
possible,  hardware  dependencies  should  be  avoided 
and  software  dependencies  should  be  minimized. 
These  should  be  used  only  when  the  benefit  is 
sufficiently  great  that  it  becomes  an  overriding 
consideration.  This  will  provide  for  easier 
maintenance  when  new  software  is  installed,  and 
faster,  easier  conversion  to  new  hardware  and  the 
accompanying  software. 

e.  Priorities.  Any  given  system  may  have 
requirements  for  a  mixture  of  accesses  and 
ordering.  Priorities  of  need  must  be  established 
in  order  to  determine  the  final  organization  of 
the  file.  For  example,  if  a  given  file  has 
requirements  for  a  large  number  of  inquiries  daily 
and  a  monthly  ordered  report,  then  the  file  should 
be  designed  to  facilitate  the  inquiries.  In  other 
words,  the  final  file  organization  and  design 
should  accommodate  the  major  use  of  the  file 
contents . 

f.  Field  Definition.  Each  field  within  the  file 
should  be  created  for  unique  contents.  No  field 
should  ever  be  used  to  contain  different  types  of 
information  under  varying  circumstances.  Each 
data  element  requires  its  own  unique  specified 
location  within  the  file,  and  should  be  constant 
in  its  meaning. 

C.  Access  Methods .  The  next  step  in  file  design  is  to  consider 
access  methods  and  their  applicability  to  the  data. 

1 .  Sequential  Access .  Sequential  access  is  applicable  to 
files  that  are  arranged  in  a  given  set  sequence,  and 
which  are  processed  entirely,  or  nearly  entirely,  each 
time  the  file  is  accessed. 
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2.  Random  Access .  Random  access  is  best  suited  to  large 
files  which  have  limited  access  requirements  and/or 
where  processing  does  not  require  any  specific 
sequence.  Access  is  by  means  of  a  key. 

3.  Direct  Access .  Direct  access  is  efficient  where  large 
quantities  of  data  exist  with  only  a  minimum  number  of 
records  accessed  at  any  given  point  in  time .  A  key 
must  be  developed  which  is  entirely  unique  to  that 
record  and  the  key  becomes  the  input  to  an  algorithm 
for  calculation  of  the  actual  address. 

D.  File  Types  and  Criteria.  There  are  several  types  of  files, 
each  appropriate  for  a  given  set  of  requirements  or 
application.  Each  of  these  should  be  considered  in  light  of 
their  inherent  strengths  and  weaknesses,  their  applicability 
to  the  requirements,  and  the  operational  overhead  in  making 
a  file-type  selection. 

1.  Data  Base.  A  data  base  provides  the  means  to  connect 
data  elements  in  such  a  manner  that  it  is  possible  to 
selectively  access  one  or  more  elements  while 
simultaneously  eliminating  data  redundancy  and  I/O 
processing  of  elements  that  are  irrelevant  to  the  task 
at  hand. 


A  data  base  file  is  indicated  when  the  following 
requirements  exist: 

a.  Many  or  complex  relationships  between  data 
elements . 

b.  Varied  access  requirements. 

c.  Access  to  only  some  of  the  data  elements  at  any 
one  point  in  time. 

d.  Diverse  processing  requirements. 

e.  Numerous  users  with  varied  requirements,  each  of 
which  has  a  different  relational  requirement 
between  data  elements. 

A  Data  Base  Management  System  (DBMS)  provides  for 
efficient  processing  when  the  above  mentioned 
conditions  exist;  however,  it  is  less  efficient  and 
more  costly  when  these  do  not  exist. 
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The  overhead  for  a  DBMS  is  usually  considerable.  For 
this  reason,  any  person  involved  in  file  design  should 
make  a  determined  effort  to  ascertain  if  the  needs 
warrant  the  use  of  DBMS. 

2.  Flat  Files.  Flat  files  are  normal  tape  and  disk  files. 
The  data  in  a  flat  file  is  self-contained,  and  rarely 
is  processed  in  conjunction  with  data  that  is  not  a 
part  of  the  file  itself;  or  data  in  another  file  which 
has  a  complex  or  varied  relationship  to  the  file. 

These  are  best  suited  where  the  following  requirements 
exist : 

a.  One  or  two  types  of  access. 

b.  Simple  relationships  between  data  elements. 

c.  Full  file  or  near  full  file  processing  at  each 
file  access. 

d.  Uncomplicated  processing  requirements. 

e.  Small  or  relatively  small  amounts  of  data. 

Flat  files  are  effective  for  files  which  have  a 
relatively  small  amount  of  data  with  definitive 
relationships  that  may  be  accessed  on  a  random  or 
direct  basis  in  a  more  or  less  regular  m’ode. 

They  are  inefficient  for  files  in  which  the  data 
element  relationships  are  many,  selective,  and  complex, 
or  where  a  variety  of  accesses  are  required. 

3.  Clusters .  An  application  technique  that  should  be 
considered  is  the  file  cluster.  A  file  cluster  is  a 
normal  first  step  in  the  direction  of  distributed  data 
processing  and  is  simply  a  logical  relationship  between 
files  which  are  connected  by  means  of  an  application 
accessing  the  members  of  the  cluster.  File  clusters 
may  be  either  clusters  of  data  bases,  or  clusters  of 
flat  files;  and  can  be  arranged  for  either  similar  or 
diverse  file  types. 

a.  Similar  File  Types.  A  file  cluster  consisting  of 
similar  file  types  is  the  more  common  cluster. 

This  consists  of  multiple  files  with  data  accessed 
individually  by  various  applications,  and  in 
addition,  one  or  more  applications  that  have  a 
need  for  simultaneous  access  and  relational 
processing  of  the  files  in  the  cluster.  An 
example  would  be  a  cluster  of  payroll,  personnel, 
and  EEO  statistics. 
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b.  Diverse  File  Types.  Clusters  of  diverse  file 

types  are  less  common,  but  are,  at  times,  the  most 
feasible  method  for  solving  some  given  problems. 
This  occurs  where  some  application  requires  access 
to,  and  relational  processing  of,  several  files 
that  would  not  normally  be  connected  in  other 
applications.  When  this  occurs,  the  creation  of  a 
file  cluster  is  indicated.  An  example  of  this 
might  be  a  cluster  consisting  of  a  personnel  file, 
a  budget  file,  and  an  expense  file. 

The  cluster  is  a  means,  therefore,  of  creating  and 
documenting  a  relationship  between  files  that 
would  not,  in  other  circumstances,  have  such  a 
connection . 

E.  Se lection .  Once  all  data  has  been  accumulated  regarding  the 

required  characteristics,  and  the  characteristics  of  the 
available  methods,  the  next  step  is  to  match  the  two  and 
select  the  most  appropriate  method. 

1.  Matching  Requirements  and  Methods.  Seldom,  if  ever,  is 
a  perfect  match  found  between  required  and  available 
characteristics.  It  is  therefore  necessary  to  make 
sacrifices  and  compromises  to  arrive  at  the  most 
feasible  approach.  However,  any  sacrifices  must  be  the 
result  of  careful  evaluation  and  deliberate  selection. 
The  selection  process,  while  relying  heavily  upon 
documented  data,  also  requires  a  certain  amount  of 
reliance  upon  factors  that  may  be  intangible.  This 
need  not  become  a  major  stumbling  block  if  the  initial 
research  has  been  thorough.  Thorough  research  will 
result  in  sufficient  knowledge  of  the  requirements  and 
the  user  operations  to  enable  more  sound  judgments  to 
be  made  regarding  trade-offs  and  long  range  benefits. 

Selection  should  be  a  painstaking  process  of  careful 
matching  of  the  required  characteristics  to  the 
available  characteristics.  All  of  the  information 
gathered  during  the  research  phase  is  carefully 
considered.  When  the  selection  is  made,  a  small  amount 
of  data  should  be  generated  to  test  the  validity  of  the 
selection.  This  constitutes  the  working  model 
described  in  the  introduction. 
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Once  the  final  selection  has  been  made,  monitoring 
should  continue  throughout  the  life  of  the  system. 

This  will  provide  for  corrections  and  modifications  as 
new  requirements  may  arise,  and  increase  the  life  span 
of  the  system. 

F.  File  Specification.  Each  data  file  designed  by  the  analyst 

must  be  standardized  in  order  to  provide  a  cohesive, 

integrated  system  that  interfaces  efficiently  with  other 

systems.  Each  file  specification  must  contain; 

*  File  Identification  and  Characteristics. 

General  Description. 

File  Abstracts. 

*  Record  Format. 

*  Data  Element  Descriptions. 

*  Appendices. 

1 .  File  Identification  and  Characteristics. 

a.  General  Description.  A  general  description  must 
be  a  brief  narrative  of  the  sources  and  general 
functional  characteristics  of  a  file.  This 
information  must  include  a  brief  description  of 
file  contents  and  purpose,  identification  of  the 
system  in  which  the  file  is  used,  a  general 
statement  of  the  source  of  data  and  how  the  file 
is  generated,  and  a  general  statement  of  the 
source  of  the  updating  cycle  and  retention 
requirements . 

b.  File  Abstracts.  The  File  Abstract  is  a  concise 
definition  of  the  physical  or  technical 
characteristics  of  a  file  in  quick  reference 

format.  Use  the  File  Abstract  Form  (FORM  NO.  _ ) 

to  describe  the  file. 

2.  Record  Format .  The  record  format  must  be  precisely 
defined  on  a  Record  Layout  Form  (FORM  NO.  ). 

3.  Data  Element  Descriptions.  Each  item  or  field  defined 
on  the  record  layout  must  be  described  and 
cross-referenced.  Use  the  Data  Dictionary  Update  (FORM 
NO.  DES  1260-8)  for  this  purpose. 
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The  Field  Name  is  cross-referenced  from  the  Record 
Layout.  Describe  the  data  element,  its  source, 
definition  of  length,  format,  and  possible  values.  In 
some  cases,  a  field  may  be  defined  for  future  use. 

If  a  security  classification  system  exists,  defining 
the  levels  and  methods  for  personnel  to  access 
information  in  specified  fields,  then  this  must  be  so 
stated.  For  example,  the  contents  of  a  field  may  be 
scrambled  and  only  specified  personnel  may  possess  the 
rules  for  interpreting  the  information.  Any  relevant 
information  for  the  understanding  of  the  data  element 
is  entered  under  Additional  Information. 

4.  Appendices .  The  appendices  are  used  to  record 

additional  optional  information  which  will  assist  in 
using  the  specifications.  Examples  include: 

a.  Edit  lists  specifying  editing  criteria  for 
acceptable  and  unacceptable  conditions  and  values 
of  various  data  elements  in  a  file. 

b.  Cross-reference  lists  specifying  indices  to  data 
elements  or  summary  tables  showing  the  frequency 
and  use  of  files  within  a  system. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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System  Logic 

Describe  the  methods  and  procedures  required  by  the  system.  All 
edits,  conditions,  logical  relationships,  techniques,  etc.,  will 
be  defined  and  documented.  Every  aspect  of  the  system  should  be 
analyzed  carefully  and  critically  to  provide  complete  and  sound 
system  logic.  Graphic  illustrations,  charts,  formulas,  etc., 
should  be  used  when  necessary  to  describe  a  system  requirement. 

A.  Decision  Logic  Tables.  Decision  Logic  Tables  (DLTs)  are 
tabular,  programmable  documentation  of  design  requirements. 
DLTs  explicitly  define  conditions /actions  relationship 
rules.  DLTs  should  be  used  to  describe  all  edits  and 
processes . 

1.  Decision  Logic  Tables  provide: 

a.  Distinct  procedures  for  reflecting  conditions  and 
actions  within  a  table  and  easy  identification  of 
their  relationship. 

b.  Display  of  alternatives  on  one  form  for  easy 
examination  and  improvement  of  logic. 

c.  Assurance  that  all  possible  combinations  of 
conditions  have  been  provided  for  in  the  rules 
shown,  such  as  associating  transaction  codes  and 
necessary  edits. 

d.  A  ready  checklist  to  enhance  better  planning  by 
the  analyst  to  reduce  decision  logic  complexity 
and  to  locate  and. reduce  decision  logic  errors. 

e.  A  good  documentation  tool  that  is  easily  prepared 
and  reviewed . 

f.  Less  dependency  on  the  original  analyst 
interpretation  by  associating  transactions  and 
necessary/required  test  data. 

2.  Ordinarily  Decision  Logic  Tables  would  not  be  used  for 

a.  Search  logic. 

b.  Format  and  print  routines. 

c.  Input/Output  routines. 

B.  Parameters/Ground  Rules.  Describe,  in  detail,  all  critical 
or  unique  conditions  and  contingencies  that  must  be 
considered  by  the  system.  The  material  may  be  outlined  in 
narrative  form,  illustrated  by  use  of  graphs  or  charts,  or 
cross-referenced  to  existing  documented  methods, 
instructions,  etc. 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


SYSTEM  LOGIC 


Section  8  (Cont.) 

These  edit /validation  rules  must  provide  the  basis  for  input 
editing,  program  logic,  and  the  control  or  rejection  of 
unacceptable  system  input.  Because  of  the  complexity  of 
some  systems,  it  may  be  advantageous  to  provide  decision 
logic  tables  to  illustrate  the  edit  and  verification 
requirements . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

F .  Guidelines  for  Designing  Program  Requirements. 

1 .  Insure  that  the  actions  to  be  programmed  have  a  logical 
flow. 

2.  Document  or  lay  out  the  programming  requirement  to 
facilitate  the  programming  effort. 

3.  Design  input  to  provide  all  necessary  control  and 
reference  data  as  well  as  operational  data. 

4.  Develop  output  requirements  with  the  user  keeping  the 
medium  and  efficient  hardware  utilization  in  mind. 


78 


DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


SYSTEM  CONTROLS 


Section  9. 
System  Controls 


Identify  and  define,  in  detail,  the  checking,  balancing,  or  other 
control  procedures  used  by  user  organizations  to  maintain 
validity  of  the  system.  Also,  describe,  in  detail,  the  internal 
processing  controls  required  by  the  system. 

Include  the  methods  used  to  provide  audit  trail  backup,  i.e.,  the 
precise  means  in  the  form  of  stored  data  file  displays,  regular 
or  special  request  printed  output  (or  any  combination  of  media), 
whereby  user  organizations  and  internal  and  external  auditors  can 
conclusively  establish  and  validate  the  specific  values  of  files 
as  of  any  selected  date,  or  changes  in  values  between  any  two 
selected  dates  or  processing  cycles. 

A.  External  Controls  for  Inputs.  Describe  the 
checking/balancing  criteria  and  control  procedures  utilized 
by  user  organization  for  each  type  system  input.  Indicate 
responsibility  for  each  control  function  and  provide 
references  to  procedure  manuals,  job  instructions, 
directives,  etc.,  used  for  system  control  support. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORMS  ). 

B.  External  Control  for  Outputs .  Identify  and  define,  in 
detail,  the  checking,  balancing,  analysis,  corrective 
methods,  or  other  procedural  control /requirements  performed 
by  user  organizations  to  maintain  the  validity  of  system 
output.  It  must  list  all  erroneous  conditions  that  may  be 
encountered  and  methods  for  correction  and  reentry  of  data. 
Similarly,  it  must  indicate  responsibility  for  each  control 
and  procedure  function,  and  for  reference  procedure  manuals, 
job  instructions,  directives,  etc.,  used  for  system  control 
support . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

C.  Internal  Files  -  Systems  Files/Data  Sets.  Describe,  in 
detail,  the  internal  controls  incorporated  within  the 
system.  For  each  file/data  set,  it  should  explain: 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


SYSTEM  LOGIC 


Section  8  (Cont.) 


FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Formulas /Calculations .  Describe  or  illustrate  the 
arithmetic  operations  essential  to  the  system.  Define  all 
requirements,  including  simple  accumulations  or  totals, 
specified  in  algebraic  terms  or  with  equations.  Define  the 
symbols  or  terms  used  in  each  equation  directly  beneath  the 
equation  or  set  of  equations. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Tables,  Charts,  and  Coding  Structures.  Define  and  describe 
any  cross-referencing,  conversion,  look-up,  or  search 
requirement  to  be  used  by  the  system  during  an  edit, 
computation,  or  other  type  processing.  Cross-reference, 
with  detail,  flow  charts,  where  applicable. 

Include  any  table  of  values  referenced  by  an  arithmetic 
calculation.  Also,  state  whether  elements  of  the  table  are 
permanent;  if  not,  specify  responsibility  for  maintenance  of 
the  table  or  chart  elements. 


Identify  Data  Element  Tables  by  name  or  title.  Each  data 
element  must  be  defined  with  respect  to  characteristics, 
terms,  and  use;  and  all  values  or  ranges  of  values  of  the 
data  element  must  be  identified  and  defined  in  detail. 

FORMS: 

SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 


Data  Edi t ing/Va 1 idat ion .  Describe  all  necessary  edit  and 
verification  operations  required  for  each  type  input  or 
transmission  to  the  system.  Identify  each  type  input  or 
transmission  and  indicate  the  tests  required  to  determine 
its  validity. 


Indicate  the  action  to  be  taken  when  an  invalid  condition  is 
encountered;  i.e.,  reject,  substitute,  identify  and  process, 
suspend,  etc. 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


SYSTEM  CONTROLS 


Section  9  (Cont.) 

1-  Balancing  Controls.  These  controls  describe  the 

contents  of  lead  records  carried  in  the  file.  Explain 
the  computer  procedures  by  which  record  counts,  dollar, 
quantity,  or  other  value  totals  in  these  lead  records 
are  generated,  and  their  use  as  controls.  Outline  the 
methods  used  for  maintaining  control  totals  from  update 
to  update.  Illustrate  the  on-line  messages  which 
provide  external  evidence  of  balanced  conditions. 

2.  Computer  Processing  Controls.  Describe  the  internal 

processing  controls  required  by  the  system.  These  will 
include  job  card  checking,  label  checking,  cycle 
generation  or  data  checking,  sequence  checking, 
check-points  and  restart  procedures,  control  of 
periodic  variations  in  procedures  and  outputs,  lockout 
features,  security  control,  and  operator  instruction 
messages,  except  as  described  in  balancing  controls 
above . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ), 

D-  Manual  Procedures.  All  of  the  manual  procedures  necessary 
to  interface  with  a  computer  system  must  be  designed  and 
documented  before  the  system  is  complete.  These  procedures 
include : 

1.  Generation  and  preparation  of  input  data. 

2.  Data  editing  and  coding. 

3.  Input  data  transmission,  logging,  and  control. 

4.  Computer  input  and  output  control. 

5.  Error  correction  and  exception  procedures. 

6.  Output  distribution. 

7.  Maintenance  of  tables,  lists,  and  master  file  data. 
Procedures  for  generation  and  preparation  of  input  data 
should  include  a  description  of  all  input  forms  used,  the 
sources  of  data  to  be  entered  in  each  area  of  the  form  and  a 
description  of  the  effect  of  each  type  of  entry. 

Data  editing  and  coding  procedures  must  incorporate  rules 
for  the  disposition  of  forms  containing  missing  or  incorrect 
data.  Such  procedures  should  contain,  as  appendices,  all 
tables  and  instructions  needed  to  properly  code  each  form. 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


SYSTEM  CONTROLS 


Section  9  (Cont . ) 

The  user  organization  originating  input  data  must  maintain 
his  own  log  of  transmittal  (Form  No.  )  providing  type  of 
data,  time  this  data  is  forwarded  to  ADP ,  and  the  control 
totals  established. 

The  routing  of  each  manual  form  must  be  described 
completely,  as  well  as  the  disposition  of  each  of  the  parts 
of  a  multiple-part  form.  Wherever  possible,  these  input 
forms  should  be  batched  and  the  Data  Transmittal  Form 
submitted  to  data  processing  with  adding  machine  controls. 
The  flow  of  controls  throughout  the  system  must  be 
documented  for  both  the  ADP  Control  Section  and  the  user 
organization  originating  the  input  data  and  receiving  the 
computer  output. 

All  data  errors  and  exceptions  not  completely  resolvable  by 
the  Control  Section  must  be  detailed  for  the  user 
organization  and  a  method  of  correction  precisely  stated. 

A  complete  procedure  must  be  created,  with  appropriate 
forms,  to  accomplish  the  maintenance  of  all  tables,  data 
lists,  or  master  file  elements  used  in  the  system.  The 
controls  for  the  completeness  and  accuracy  of  these  tables, 
lists,  and  fields  must  be  detailed  in  this  procedure. 

Guidelines  for  the  Design  of  Manual  Procedures: 

1.  Manual  procedures  are  to  be  kept  as  simple  as  possible. 
Numerous  exceptions  or  options  must  be  avoided. 

2.  Unless  absolutely  unavoidable,  table,  list,  and  master 
file  changes  must  originate  from  a  central  source,  or 
must  pass  through  a  central  control  point. 

3.  Each  significant  field  on  the  forms  must  contain  an 
entry.  That  is,  for  blank  field,  the  inclusion  of  a 
code,  or  a  check  mark,  should  be  required  to  indicate  a 
positive  condition,  rather  than  the  assumption  of  a 
condition  if  the  field  is  blank. 

The  specific  operations  and  procedures  to  be  followed,  and 
their  corresponding  sequence,  is  outlined  in  the  diagram  on 
the  following  pages.  The  Manual  Procedures  described  must 
be  followed  to  facilitate  system  processing.  Each 
organizational  unit  must  perform  its  assigned  tasks  in  the 
sequence  specified. 
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MANUAL  PROCEDURES 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


COMPUTER  PROCESSING 


Section  10. 

Computer  Processing 

The  description  and  documentation  of  the  processing  logic  of  the 
system  will  contain  functional  flow  charts,  complete  program 
descriptions,  and  interrelationships.  Also  included  are  detail 
plans  or  programs  for  data  file/data  set  conversions  required  for 
parallel  processing  or  for  final  production  implementation. 

A.  Guidelines  for  Designing  Processing  Operations: 

1.  Design  program  functions  to  minimize  requirements  for 
special  operator  actions. 

2.  Establish  program  run  sequences  to  minimize 
requirements  to  hang  or  remove  tape. 

3.  Insure  that  input  data  required  for  program/ system 
operation  is  readily  identifiable,  received  by  the 
operators  in  logical  sequence,  and  requires  minimal 
evaluation  and  corrective  action  by  the  operators. 

4.  Prepare  computer  run  sheets  to  clearly  define 
operator's  actions  and  other  run  requirements.  Insure 
that  the  run  sheets  are  kept  current . 

5.  Furnish  the  operators  clear  and  complete  guidance  on 
actions  to  take  in  the  event  of  program,  system, 
equipment,  or  environmental  failure. 

B.  Computer  Processing  Flow  Chart.  The  Computer  Processing 
Flow  Chart  differs  from  the  Detailed  System  Flow  Chart, 
which  was  developed  in  Section  3  of  this  chapter,  and 
included  all  functions,  processes,  and  procedures,  both 
inside  and  outside  the  Operations  area,  but  incorporated  the 
computer  processing  in  a  single  box.  The  Computer  Flow 
Chart  is  an  expansion  or  "blow-up"  of  the  computer 
processing  and  will  provide  an  overall  picture  of  the 
identification  and  relationship  of  processing  segments, 
sequences,  data  sets / files /data  bases,  inputs,  and  outputs. 

FORMS; 

SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 
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SYSTEM  COMPOr^EWTS  IDENTiFiCATiO 


SYSTEM  NAME 


COMPONENT  CLASS 


■  ITEM  NO.- 


•  TITLE - 


•REFERENCE  PAGE 


FORM  NO. 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


COMPUTER  PROCESSING 


Section  10  (Cont.) 

C-  Computer  Program  Index.  Identify  and  index  each  program 

used  by  the  system  or  system  segment.  "Program"  is  defined 
as  every  program  written  specifically  for,  or  used  by,  the 
system.  This  includes  utility  software  programs  which  are 
modified  by  control  cards  or  other  methods  to  satisfy  the 
requirements  of  the  system.  It  does  not  include  unmodified 
utility  programs.  Generalized  sub-programs /sub-rout ines 
utilized  by  the  major  programs  are  described  on  Page  6  of 
this  section. 

Instructions  for  the  completion  of  the  System  Components 
Identification  Form  (FORM  NO.  )  are: 

1-  System  Name  -  Enter  the  official  name  of  the  system. 

2.  Components  Class  -  Enter  "Programs"  to  denote  that 
items  listed  are  programs  used  by  the  system. 

3.  Titl e  -  Enter  the  title  of  the  program. 

Reference  Page  -  Enter  the  page  number  containing  the 
program  function  description/f low  charts. 

D .  Computer  Program  Functional  Description/Flow  Charts . 

Describe  each  computer  program  listed  on  the  System 
Components  Identification  Form  as  to  its  purpose,  function, 
and  relationship  to  the  system.  Each  description  should 
contain  sufficient  detail  to  enable  a  programmer  to  block 
diagram,  code,  and  test  the  program  and  otherwise  complete 
the  programming  function. 

Information  regarding  each  program  should  be  portrayed  in 
the  following  format: 

Program  Title _ _ _ 

Program  No. _ 

Machine_ _ ^Est  .  Run  Time _ 

Processor _  Language _ 

Program  Function: _ 


Program  Title  -  Enter  the  assigned  name  or  title  of  the 

program. 

Program  Number  -  Enter  the  program  identification 
number . 

Machine  -  Enter  the  machine  type  and  model  number. 
Estimated  Run  Time  -  Indicate  an  estimated  program  run 
time . 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


COMPUTER  PROCESSING 


Section  10  (Cont.) 

Processor  -  Indicate  the  language  processor  used  for 
program  compilation;  e.g.,  COBOL,  etc. 

Language  -  Indicate  the  programming  language  used; 
e.g.,  COBOL,  FORTRAN,  etc. 

Program  Function  -  Provide  a  detailed  description  of 
what  the  program  does.  These  functions  should  be 
enumerated  in  numbered  paragraphs  or  sentences .  Make 
cross-reference,  if  applicable,  to  sub-routines  and/or 
tables . 

Flow  Charts  -  Attach  program  flow  charts,  where 
applicable,  to  illustrate  processing  logic  for  complex 
requirements . 

FORMS: 

SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 

E.  Sub-Program/Sub-Routine  Descriptions .  Describe  generalized 
sub-programs  or  routines  utilized  by  the  major  programs. 
Provide  descriptions  of  the  specialized  functions  and  logic 
of  all  sub-programs /routines ,  using  a  separate  page  for 
each;  describe  the  modular  construction,  if  applicable,  and 
identify  all  source  (or  control)  programs  which  call  for 
this  particular  sub-program/ rout ine . 

To  simplify  documentation  and  avoid  redundancy,  provide 
cross-reference  to  appropriate  sections  of  the 
design/specifications  procedures,  e.g., 
formulas /calculations ;  tables,  charts,  and  coding 
structures;  data  editing/validation;  system  controls;  etc. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

F.  File/Data  Set  Conversion  Procedures.  Describe  the 
conversion  plan  and  designate  associated  support  effort 
required  for  system  implementation.  This  plan  should 
outline  all  details  for  new  file  initialization  as  well  as 
for  conversion  of  existing  files,  data  sets,  or  data  bases. 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


COMPUTER  PROCESSING 

Section 

10  (Cont.) 

Each  task  should  be  specifically  defined.  In  many  cases, 
user  support  must  be  available.  Specify  the  directions  and 
estimated  amount  of  time  required  for  customer  assistance  in 
verifying  the  accuracy  of  new  or  converted  files,  data  sets, 
or  data  bases,  during  parallel  or  initial  production 
processing.  Indicate,  where  applicable,  any  interface 
considerations . 

FORMS:  SYSTEM  DOCUMENTATION  (a)  (FORM  NO.  ). 

G. 

Disaster/Recovery  Backup  Procedures.  Describe  the 
procedures  and  techniques  for  system  recovery  in  the  event 
of  loss  of  file  or  file  integrity. 

Assume  the  "worst  case"  disaster  situation  which  causes 
complete  destruction  of  all  records  within  Ooerations.  and 
outline  the  detailed  steps  by  which  the  current  status  of 
data  files  could  be  reconstructed  from  copies  of  source 
documents,  printed  reports,  stored  files,  or  any  combination 
of  all  media.  Consider  all  possibilities,  including 
activation  of  manual  systems,  etc. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


DEVELOPMENT / IMPLEMENTATION  SCHEDULE 


Section  11. 

Development /Implement  at  ion  Schedule 

Specify  due  dates  for  system  implementation,  data  input,  and  data 

output . 

A.  System  Implementation  Schedules.  Indicate,  in  a  schedule 
form,  estimated  dates  for  the  completion  of  the  Operations 
Manual  (Run  Book),  Program  Maintenance  Manual,  Users  Manual, 
and  job  acceptance  and  implementation  by  the  Operations 
Section . 

1.  Operations  Manual  (Run  Book) .  The  Operations  Manual 
will  provide  Computer  Operations  personnel  with  a 
description  of  the  software  and  of  the  operational 
environment  so  that  the  software  can  be  run. 

(Reference  "Operations  Manual"  -  Chapter  5,  Section  9 
of  this  Manual). 

2.  Program  Maintenance  Manual.  The  Program  Maintenance 
Manual  will  provide  the  maintenance  programmer  with  the 
information  necessary  to  understand  the  programs,  their 
operating  environment,  and  their  maintenance 
procedures.  (Reference  "Program  Maintenance  Manual"  - 
Chapter  5,  Section  10  of  this’ Manual ) . 

3.  Users  Manual.  The  Users  Manual  will  sufficiently 
describe  the  functions  performed  by  the  software  in 
non-ADP  terminology,  such  that  the  user  organization 
can  determine  its  applicability  and  when  and  how  to  use 
it.  It  should  serve  as  a  reference  document  for 
preparation  of  input  data  and  parameters  and  for 
interpretation  of  results.  (Reference  "Users  Manual'  - 
Chapter  5,  Section  11  of  this  Manual). 

Compare  the  scheduled  implementation  date  with  the  original 
estimate  shown  on  the  Project  Management  Chart.  Make 
adjustments,  as  required,  to  the  project  management  data. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

B.  Input  and  Output  Due  Dates.  Indicate,  in  schedule  form,  the 
frequency  and  timing  for  the  submission  of  each  type  of 
input  by  the  user  organization  and  the  frequency  and  timin 
for  the  production  of  each  type  of  output  by  the  Operation 
Section . 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


DEVELOPMENT / IMPLEMENTATION  SCHEDULE 


Section  11  (Cont.) 

Development,  implementation,  and  input/output  schedules  will 
be  developed  jointly  by  the  User  and  Data  Processing 
personnel . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  DESIGN/SPECIFICATIONS 


GLOSSARY  OF  TERMS /ABBREVIATIONS 


Section  12. 

Glossary  of  Terms/Abbreviations. 

List  all  technical  terms,  words,  phrases,  and  abbreviations  which 
require  further  explanation  and  definition.  This  list  should  be 
arranged  in  alphabetical  order  with  each  item  underlined.  Before 
finalizing  this  list,  review  each  section  of  the 
Design/Specifications  carefully  to  insure  inclusion  of  all 
necessary  items. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE  -  PROGRAMMING 


INTRODUCTION 


Section  0. 
Introduction 


During  the  programming  stage  of  development,  the  software  is 
coded  and  debugged.  Documents  which  should  be  prepared  or 
updated  during  this  stage  include  the  Users  Manual,  Program 
Maintenance  Manual,  and  Operations  Manual. 
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Programs  should  be  developed  as  a  set  of  modular  programs.  This 
is  a  simple  approach  that  allows  for  the  easy  addition  and 
deletion  of  subroutines.  The  main-line  program  should  be  simple 
and  should  branch  to  subroutines  which  are  self-contained, 
thereby  offering  the  best  conditions  for  future  program 
modifications . 
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Section  0  (Cont . ) 

This  technique  has  considerable  efficiencies  in  programming  time, 
computer  time,  and  maintenance  time  since  it  enables  complex 
problems  to  be  segmented  into  many  simple  sections.  A  modular 
program  reflects  the  program  organization  established  in  the 
systems  modular  flow  chart. 

The  primary  design  criteria  of  modular  programming  are  ease  of 
understanding,  ease  of  program  modification,  and  standardization 
of  program  construction. 
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Section  1. 

Project  Team  Administration. 

A.  Upon  completion  of  the  Design/Specifications  Phase,  the 
responsible  project  team  member(s)  will: 

1.  Review  program  design  specifications. 

2.  Prepare  a  brief  narrative  description  of  each  program. 

3.  Prepare  a  logic  flow  chart  for  each  program  which 
pictorially  represents  the  steps  through  which  the 
program  is  to  process  data. 

4.  Identify  and  define,  in  detail,  all  specialized 
techniques  and  tables  utilized  by  complex  programs. 

5.  Describe  the  file  organization  for  each  input/output 

file.  Also  cross-reference  each  file  in  the  system  to 
the  specific  programs  that  either  create,  change,  or 
utilize  the  file. 

6.  Describe  the  program  controls  used  to  provide  the  means 
for  insuring  the  accuracy  of  both  data  preparation  and 
program  operations. 

7.  Select  the  program  language,  write  source  code  for  the 
program  using  the  logic  flow  chart  as  a  guide,  and 
generate  a  syntax  free  program  compile. 

8.  Prepare  operation  manual. 

9.  Prepare  program  maintenance  manual. 

10.  Prepare  users  manual. 

B.  Walk-Through.  The  members  of  the  walk-through  team  will 
vary  in  accordance  with  the  material  being  reviewed.  The 
walk-through  is  chaired  by  the  Project  Coordinator  and 
conducted  by  the  individual  responsible  for  the  material. 

The  purpose  of  the  walk-through  is  to  determine  if  all  of 
the  program  requirements  have  been  identified  and  defined, 
and  to  evaluate  the  required  documentation  for  completeness 
and  accuracy.  Review  the  work  plan  for  the  Test  Phase 
during  the  walk-through  and  make  adjustments  to  the  plan  and 
project  management  data  as  required. 

The  Programming  Phase  must  be  approved  by  the  responsible 
individuals  and  management  before  the  Test  Phase  can  be 
initialized . 
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Section  2. 

Review  Program  Design  Specifications 

All  functional  program  requirements  should  be  identified  and 
specified  in  the  design  as  the  first  step  in  program  development. 

Review  the  program  design  specifications.  Discuss  the 
organization  plan  for  each  program  with  the  analyst,  and  resolve 
any  misunderstandings  or  differences  of  opinion. 
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NARRATIVE  PROGRAM  DESCRIPTION 

Section  3. 

Narrative  Program  Description 

The  program  description  is  a  narrative  briefly  describing,  in 

nontechnical  terms,  the  program's  major  functions,  procedures, 

special  features,  and  equipment  requirements. 

A.  Identification.  Indicate  system  name,  program  name  and 
number,  programmer  and  analyst  name,  and  data  narrative 
written. 

B.  Statement  of  Purpose.  Indicate  the  form  of  the  input,  the 
processing  required,  and  the  output  expected.  State,  in 
specific  terms,  the  objectives  of  the  program  and  its 
requirements.  Also,  specify  the  relationship  of  the  program 
to  other  programs  in  the  system. 

C.  Special  Features.  Indicate  programming  features  used  for 
calculations,  logic  tests,  edits,  error  specifications,  and 
recovery  procedures.  Explain  requirements  for  tables,  if 
used . 

D.  Special  Requirements.  Indicate  input /output  requirements, 
list  on-line,  off-line  equipment  with  special  features, 
number  of  tape  drives,  core  size,  disk  capacity,  etc.;  also, 
list  any  special  subroutines  required. 

E.  Controls .  Indicate  the  programming  controls  included  in  the 
system. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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Section  4. 

Program  Logic  Flow  Chart 

The  Logic  Flow  Chart  is  a  pictorial  representation  of  the 
program.  It  is  the  diagram  of  operations  and  decisions  along 
with  the  sequence  in  which  they  are  performed  by  a  computer. 

Each  symbol  must  describe  a  single  program  instruction  or 
stand-alone  procedure.  The  flow  chart  must  precisely  follow  the 
program  logic. 

The  Logic  Flow  Chart  must  be  cross-referenced  to  the  source 
language  program  in  order  to  be  an  optimum  aid  in  program 
bebugging,  maintenance,  and  modification.  The  text  written 
inside  each  symbol  must  not  only  identify  the  function  of  the 
program  segment  but  must  also  correspond  to  the  internal 
identification  of  the  segment.  In  the  COBOL  language,  for 
example,  this  would  include  the  COBOL  section  or  paragraph  name. 

FORMS:  SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 

A.  Decision  Logic  Tables.  Decision  Logic  Tables  (DLTs)  are 
tabular,  programmable  documentation  of  design  requirements. 
DLTs  explicitly  define  conditions /actions  relationship 
rules.  DLTs  should  be  used  to  describe  all  edits  and 
processes.  Decision  Logic  Tables  provide: 

1.  Definition  of  detailed  edit  and  validation 
requirements . 

2.  Definition  of  update  processing  logic. 

3.  Definitions  of  requirements  for  report  extracting. 

4.  A  good  documentation  tool  that  is  easily  prepared, 
reviewed,  and  updated  as  the  system  is  modified  and 
changed. 

B.  Guidelines  for  Designing  Modu lar  Programs.  Designing 
programs  in  a  modular  fashion  may  increase  the  time  required 
for  the  planning  phase  of  program  development.  However,  the 
total  time  required  for  program  development  is  significantly 
reduced  due  to  savings  in  the  testing,  debugging,  and 
maintenance  phases. 

1.  To  design  a  modular  program,  the  programmer  will: 
a)  Determine  the  program  requirements. 
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PROGRAM  LOGIC  FLOW  CHART 


Section  4  (Cont . ) 


b)  List  the  requirements,  elements,  and  functions  of 
the  program  as  they  come  to  mind,  giving  no 
attention  to  logical  order. 

c)  Determine  the  logical  order  of  the  processing 
routines  and  design  the  mainline  of  the  program. 

d)  Construct  the  mainline  so  that  the  largest  volume 
of  data  is  processed  by  the  lowest  number  of 
instructions  (a  fast  mainline  contributes  greatly 
to  the  throughput  capabilities  of  a  program). 

e)  Draw  the  program  logic  flow  chart  (careful 
attention  will  be  given  to  this  flow  chart  because 
it  will  tend  to  reveal  most  errors  in  logic). 

f)  Draw  the  routine  or  routines  forming  each  module 
in  diagram  form. 

g)  Flow  chart  each  routine  to  the  desired  level  of 
detail . 

Mainline  Components .  The  following  segments  are 
generally  found  in  the  mainline  of  most  programs; 

a)  Housekeeping.  This  segment  is  used  to  initialize 
certain  counters  and  areas,  and  open  and  check 
files  before  obtaining  a  record. 

b)  Input  Handling.  This  section  of  the  program  gets 
the  record,  sequence  checks  the  files,  updates  the 
input  control,  and  handles  read  errors. 

c)  Processing.  The  mainline  selects  and  transfers 
control  to  the  appropriate  processing  routines  in 
the  proper  sequence. 

d)  Output  Handling.  Generally  these  are  instructions 
to  be  executed  just  before  disposing  of  a  record. 
For  example,  records  are  positioned,  accounted 
for,  formatted,  and  dispatched. 

e)  End  of  Job.  Included  are  routines  to  close  files 
and  verify  control  totals. 

Mainline  Conventions.  The  following  conventions  should 
be  adhered  to  by  the  programmer  in  developing  the 
mainline  portion  of  a  program: 

a)  The  mainline  will  make  all  decisions  governing  the 
flow  of  data  to  the  proper  processing  routine  on 
the  same  level. 

b)  No  processing  routine  will  direct  data  flow  to 
another  processing  routine  on  the  same  level. 
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c)  Subordinate  processing  routines  may  be  entered 
from  a  processing  routine  if  required. 

d)  Input  and  output  functions  common  to  more  than  one 
processing  routine  will  be  controlled  by  the 
mainline. 

e)  All  common  areas  will  be  defined  as  part  of  the 
mainline. 

4.  Processing  Routine  Conventions .  A  separate  processing 
routine  is  created  for  each  logical  segment  of  the 
program  and  will  accomplish  one  task  in  its  entirety. 
The  following  conventions  should  be  adhered  to  by  the 
programmer : 

a)  Each  processing  routine  will  be  complete  within 
itself.  No  decision  made  outside  the  routine  will 
determine  the  processing  within  a  routine  and  no 
decision  within  a  routine  will  determine  the 
processing  outside  the  routine. 

b)  Each  routine  will  be  designed  so  it  is,  in  effect, 
a  closed  subroutine.  Control  is  transferred  to 
the  processing  routine  from  the  mainline,  and  when 
the  routine  has  performed  its  function  it  sends 
control  back  to  the  mainline. 

c)  A  processing  routine  may  transfer  control  to  a 
multiple-use  subroutine.  When  that  subroutine  has 
performed  its  task,  it  transfers  control  back  to 
the  processing  routine. 

d)  Input  or  output  functions  that  affect  only  one 
processing  routine  may  be  performed  by  that 
routine . 

e)  Any  results  of  processing  to  be  passed  back  to  a 
higher  level  module  will  be  stored  in  an  area  in 
that  higher  level  module. 

5.  FORTRAN  Modular  Programming  Guidelines.  FORTRAN,  with 
its  powerful  procedure  and  subprogram  features,  is 
ideally  suited  to  the  concept  of  modular  programming. 
The  advantages  to  this  approach  include  simplified 
maintenance,  more  efficient  testing,  easier 
programming,  and  increased  flexibility. 

FORTRAN  programmers  should  adhere  to  the  following 
guidelines  regarding  modularity; 
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a)  The  optimum  modular  program  will  consist  of  a 
series  of  functional  units  which  are  dependent  on 
the  mainline  program. 

b)  Each  large  module  (more  than  50  statements)  will 
be  analyzed  to  see  if  it  can  be  divided  into 
smaller  modules.  The  mainline  will  serve  as  a 
control  program  and  data  transfer  point.  The 
argument  lists  used  to  communicate  data  to  the 
procedures  and  subprograms  will  be  restricted  to 
less  than  15  items.  If  additional  data  is 
required,  communication  through  COMMON  will  be 
used  to  supplement  the  argument  list. 

c)  All  input/output  routines  will  be  isolated  to  a 
single  routine  in  a  program  or  a  single  program  in 
a  system.  This  technique  is  implied  in  modular 
programming,  but  will  be  used  even  if  a  program  is 
not  written  in  a  modular  fashion. 

d)  The  statement  label  of  instructions,  which 
generates  output,  will  be  included  as  part  of  the 
output  routine.  This  technique  is  useful  in 
maintaining  machine  independence  and  flexibility. 
Actual  assignment  of  unit  codes  will  be  placed  in 
COMMON  or  read  in  as  control  information. 
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Section  5. 

Techniques /Tables 

Supporting  the  diagrammatic  representation  of  the  logic  flow 
chart  is  a  section  on  Techniques  and  Tables.  This  is  an  optional 
section  which  is  to  be  used  for  complex  programs  with  specialized 
requirements . 

Tables  and  techniques  which  are  self-explanatory  by  reference  to 
the  program  listing  do  not  require  any  special  description.  This 
Techniques  and  Table  Section  may,  however,  be  required  for  such 
items  as: 

*  Complex  table  structures. 

*  Special  search  techniques. 

*  Randomizing  formulae. 

*  Special  access  formulae. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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Section  6. 

Input/Output 

For  each  input/output  file,  the  data  organization  must  be 
specified.  If  applicable,  sorting  sequence  should  be  specified 
in  major  to  minor  order.  Indexes  and  control  fields  must  be 
described.  If  several  files  are  logically  connected  in  an  input 
series,  this  must  be  explained. 

Standard  label  formats  must  be  specified  for  standard-label 
files . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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Section  7. 

Control  Information 


Controls  is  a  series  of  explanatory  paragraphs  defining  how 
program  controls  imposed  on  inputs  and/or  outputs  operate.  They 
should  be  sufficiently  detailed  so  that  reviewers  can  determine 
whether  the  controls  satisfy  their  design  requirements.  Included 
would  be  such  controls  as  record  counts,  accumulated  counts, 
batch  controls,  etc. 

How  Controls  accomplish  control  should  be  stressed  so  that  their 
validity  and  integrity  can  be  satisfactorily  confirmed. 

A.  Program  controls  should  include  controls  on: 

1.  Transmission  of  data  from  user  or  originating 
department  to  ADP . 

2.  Conversion  of  source  documents  to  machine-readable 
form. 

3.  Creation  and  updating  of  master  files. 

4.  Transmission  of  data  from  program  to  program, 
establishing  that  data  output  from  one  program  is 
intact  while  serving  as  input  to  another.  These 
controls  must  flow  through  utility  programs  and  sorts 
as  well  as  application  programs. 

5.  Handling  of  error  and  exception  conditions  and  their 
resolution. 

B.  Controls  should  be  consistent.  Except  for  data  origination 
points  or  information  resulting  from  calculations,  each 
control  figure  must  be  derivable  from  controls  existing  at  a 
previous  step. 

C.  Controls  should  be  explicit.  Clearly  state  the  course  of 
corrective  action  to  be  taken  if  out-of-balance  conditions 
exist . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 


101 


UNITED  STATES 

DEPARTMENT  OF  THE  INTERIOR 

BUREAU  OF  LAND  MANAGEMENT 


COBOL 


CODING 

FORM 


PROGRAM 

PROGRAMMER 

DATE 

SYSTEM 

SHEET  OF 

IDENTIFICATION 

73 

74 

75 

76 

77 

78 

79 

80 

PAGE 


LINE 


COBOL  STATEMENT 


1  2  3 


4  5  6 


8  9  10  11 


12  13  14  15 


16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  4  3  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72 


I 


GPO  850-282 


DSC- 1265-28  (Oct.  1973) 


102a 


DEVELOPMENT  PHASE  -  PROGRAMMING 


CODE /COMPILE 


Section  8  (Cont.) 

Paragraph  names  should  be  descriptive  of  the  function 
being  performed  within  each  paragraph.  Each  paragraph 
should  have  a  sequential  numeric  prefix  for  easy 
identification . 

EXAMPLE:  85-COMPUTE -WAGES 

COMPUTE -WAGES  =  HRS  X  RATE 

Mnemonics  are  helpful  when  used  for  file 
identification,  operations,  subroutines,  and  other 
program  parts.  They  should  be  descriptive  and 
meaningful  to  assist  the  reader  whenever  possible. 

3.  Limitations .  Statements  such  as  nested  IF  condition 
codes  should  be  avoided.  Logic  switches  can  be 
troublesome.  Avoid  the  use  of  switches  by  using 
self-contained  subroutines.  If  switches  are  used, 
document  completely.  Limit  the  use  of  GO  TO  verbs. 

4.  Tables .  Tables  should  be  used  whenever  possible.  This 
technique  makes  changing  a  program  easier. 

5.  Conserve  Memory  and  Other  Resources .  Programmers 
should  attempt  to  conserve  core  memory  as  much  as 
possible  through  the  use  of  various  programming 
techniques . 

a)  Use  a  single  READ  or  WRITE  statement  per  file. 

b)  Use  a  single  OPEN  or  CLOSE  statement  for  multiple 
files . 

c)  Use  I/O  buffers  rather  than  work  areas  to  speed 
processing. 

d)  Carefully  design  SORT  work  area  allocation. 

e)  Use  temporary  data  sets  for  intermediate  file 
processing . 

6.  Data  Control.  All  records  should  be  sequence  checked 
or  computer  sorted  on  input  when  performing  sequential 
updates.  Audit  trails  should  be  developed  by  dating 
and  logging  all  transactions. 

D.  Program  Logic  Switches.  For  each  internal  logic  switch  used 
in  the  program,  a  Switch  Chart  Form  must  be  completed. 
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Code/Compile 

A.  Program  Language.  When  a  clear  understanding  of  the  program 
requirements  has  been  attained,  the  next  step  in  the 
development  of  the  program  is  the  selection  of  a  programming 
language . 

1.  COBOL .  (COMMON  BUSINESS  ORIENTED  ^LANGUAGE) .  COBOL 
will  be  used  as  the  standard  language  in  programming  of 
production  business  applications. 

2.  FORTRAN .  (FORMULA  TRANSLATING) .  FORTRAN  will  be  used 
for  scientific  and  advanced  mathematical  applications. 

3.  BASIC.  (BEGINNERS  _^L-PURPOSE  SYMBOLIC  INSTRUCTION 
CODE ) .  BASIC  should  be  used  only  in  an  "open  shop"  or 
time-sharing  environment. 

B.  Code .  Following  the  selection  of  a  programming  language, 
the  program  is  coded  using  the  program  logic  flow  chart 
and/or  decision  logic  tables  as  a  guide. 

FORMS:  COBOL  Coding  (FORM  NO.  DSC  1265-28). 

C.  Programming  Guidelines .  These  guidelines  are  established  to 
keep  programs  relatively  simple,  readily  modifiable,  and 
understandable  to  all  levels  of  programming  personnel. 

1 .  Generalized  Programs.  Programs  should  be  developed 
with  as  much  flexibility  as  possible  by  the  use  of 
generalized  routines  which  call  upon  external  control 
methods  for  the  specific  parameters  required  for  each 
run. 

2 .  Use  of  Statements,  Notes,  and  Mnemonics.  Each  program 
control  should  contain  only  one  statement.  This  makes 
it  easier  to  insert  new  statements  or  change  existing 
one. 

Note:  Statements  should  be  used  liberally  throughout 

the  program  to  describe  what  is  being  done.  This 
information  is  invaluable  documentation  for  maintenance 
and  system  enhancement  purposes,  particularly  when  the 
assigned  maintenance  programmer  did  not  prepare  the 
prior  program  version. 


102 


DEVELOPMENT  PHASE  -  PROGRAMMING 


CODE /COMPILE 


Section  8  (Cont . ) 

Instructions  for  the  completion  of  the  Switch  Chart  Form 

(Form  No.  )  are: 

1 .  Swit ch  Name.  Use  to  denote  the  internal  data  field 
followed  by  a  descriptive  switch  name. 

2.  Switch  State.  Use  to  describe  each  possible  switch 
value.  One  line  is  used  to  represent  an  individual 
switch  state.  One  summary  line  must  be  included  for 
invalid  values  that  will  cause  a  given  program  action. 

3.  State  Meaning.  Use  to  briefly  describe,  for  each 
switch  state,  the  meaning  of  the  given  value. 

4.  Value  Source.  Use  to  indicate  the  source  of  the  given 
value  for  the  switch,  e.g.,  input  card,  current  master 
file  record,  prior  master  file  record,  prior  output 
record . 

E .  Compile . 

1 .  Desk  Checking.  When  the  coding  for  a  program  has  been 
completed,  the  natural  inclination  is  to  compile  it  and 
see  how  it  looks.  However,  time  spent  in  desk  checking 
can  be  very  productive.  Desk  checking  is  usually  the 
last  detailed  review  of  each  functional  section  of  the 
program.  It  provides  an  opportunity  to  see  that  all 
required  processing  features  have  been  included  and 
determine  a  proper  relationship  between  the  various 
program  components.  Particular  attention  should  be 
paid  to  all  structures  in  the  Data  Division,  input  and 
output  routines,  control  break  routines,  accumulation 
of  totals,  subscripting,  and  end-of-file  routine. 

Desk  checking  must  be  performed  in  a  relatively  quiet 
atmosphere  with  few  outside  distractions.  The 
programmer  must  simulate  the  computer  by  "walking"  data 
through  each  routine,  keeping  in  mind  the  functional 
requirements  of  the  program. 

2.  Pre-Compilation  Desk  Checking.  The  objective  of  this 
step  is  to  achieve  maximum  benefit  of  the  first 
compilations  by  removing  coding  errors  that  would 
terminate  compilation  prematurely,  or  cause  an 
excessive  number  of  compilation  errors. 

Desk  checking  is  performed  against  an  80  -  80  program 
listing,  if  this  can  be  obtained  quickly  and  cheaply; 
otherwise  against  an  interpreted  card  deck. 
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Check  specifically  for: 

a)  Correct  spelling  and  placement  of  each  of  the  four 
required  COBOL  divisions  and  their  associated 
sections . 

b)  Correct  punctuation,  especially  quotes  and 
periods . 

c)  Correct  card  deck  sequence. 

d)  Correct  external  names  in  copy  statements. 

e)  Correct  Data  Division  structures. 

3.  Program  Code  Compilation.  Upon  completion  of  desk 

checking  the  program  code  will  be  compiled  for  syntax. 
Once  a  syntax-free  compilation  is  achieved,  a  source 
program  listing  will  be  generated  which  contains  the 
sequential  organization  of  the  program  instructions  in 
the  source  language.  When  applicable,  a  program 
cross-reference  listing  should  also  be  generated. 
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Operations  Manual 


Each  production  system  must  provide  for  a  complete  and  clear 
operating  guide  which  specifically  defines  the  processing 
functions  and  responsibilities  with  respect  to  the  programs  and 
control  procedures. 

This  section  will  set  forth  the  procedures  to  be  followed  in 
documenting  a  production  job  stream.  The  final  form  of  the 
documentation  described  here  shall  be  called  an  Operations 
Manual.  The  contents  of  one  Operations  Manual  shall  describe  one 
production  job  stream,  which  would  usually  include  the  execution 
of  more  than  one  program.  The  Operations  Manual  provides 
instructions  to  be  used  by  Operations  personnel  in  scheduling, 
setting  up,  and  running  a  given  job. 

A.  Title  Page.  The  first  page  of  every  operations  manual  must 
be  a  title  page.  The  Title  Page  identifies  the  system  and 
also  provides  an  area  for  signing  off  as  the  different 
stages  of  development  are  completed. 

The  signature  of  the  responsible  individual  is  required: 

1 .  After  the  Operations  Manual  has  been  reviewed  for 
completeness  and  accuracy  during  the  walk-through. 

2.  After  the  program  and  system  testing  has  been 
successfully  completed  and  it  is  determined  that  the 
documentation  is  consistent  with  the  processing 
requirements . 

3.  When  the  system  is  placed  into  a  production  status  and 
formally  accepted  by  the  Computer  Operations  Sections. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

B.  Table  of  Contents.  The  Table  of  Contents  will  contain  a 
list  of  all  documents  associated  with  an  Operations  Manual 
and  their  corresponding  page  numbers.  In  the  event  that  an 
item  is  not  required  to  describe  a  particular  job  stream,  it 
should  specify,  in  the  page  column,  NA  for  not  applicable. 
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Console  Messages 
Job  Carriage  Tape  Layouts 
Special  Forms _ 

\r 

'Computer 

Operation 


Sys  tern 


System  Overview 
System  Job  Flow  Charts 
Program  Descriptions 
File  Descriptions 
Report  Definitions 


Operations  Manual 


Product  ion 
Control 


Data  Control 


Data  Submission 

Data  Keying  Instructions 


Scheduling  Requirements 
Job  Initiation  Instructions 
Parameter  Record  Definitions 
Restart /Rerun  Procedures 
Balancing  Instructions 
Report  Distribution 
Off-Site  Transmittal 
Work  Flow  Language 


FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

C .  System. 

1.  System  Overview.  The  System  Overview  is  a  short 

narrative  summarizing  the  purpose  and  scope  for  the 
system.  A  brief  description  of  each  program  within  the 
system  must  also  be  stated,  as  well  as  run  frequencies 
and  interactions  with  other  system  and  files. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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2.  System  Job  Flow  Charts.  The  System  Job  Flow  Chart 
provides  Production  Control  personnel  with  a  graphic 
overview  of  each  system  job.  One  flow  chart  is 
prepared  for  each  job.  The  system  job  flow  chart 
section  is  the  only  documentation  that  provides  a 
chronological  overview  of  the  job  step  execution 
sequence  of  all  system  jobs. 

The  system  job  flow  chart  should  contain  all  programs, 
files,  reports,  and  parameter  records  of  the  system. 
Graphic  blocks  for  programs,  files,  and  reports  should 
be  marked  with  their  respective  unique  identification 
code  and  title. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

3.  Program  Descriptions.  The  Program  Description  provides 
a  brief  narrative  of  functions  of  each  program  in  the 
system. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

4.  Report  Definitions.  The  Report  Definition  is  a  brief 
description  of  each  report  produced  by  the  system. 

FORMAT: 

(Report  ID)  (Report  Title) 

XXXXXXXXXXXXXX  XXXXXXXXXXXXXXXXX 

(Report  Description) 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

D  .  Production  Control . 

1.  Scheduling  Requirements.  Describe  the  scheduling 
requirements  of  each  job  in  the  system.  The 
information  required  for  scheduling  is  documented 
partly  with  a  narrative  description  and  partly  with  a 
File  Specification  Description. 

a.  Narrative  Description.  The  narrative  description 
lists  the  characteristics  of  the  system  that  could 
affect  the  scheduling  of  the  run.  These  include: 
1)  Frequency  of  the  job. 
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2)  Calendary  requirements,  e.g.,  day  of  week, 
day  of  month,  working  day  of  month,  etc. 

3)  Relationships  with  other  production  systems. 

4)  Estimated  run  time. 

5)  System  utilities  required. 

6)  Data  base  requirements. 

7)  Core  memory,  disk,  and  tape  units  required 
for  each  run  unit. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
b.  File  Specifications.  Describe,  in  detail,  the 
file  specifications  for  each  program  in  the 
system. 

FORMAT: 


Program 

ID 

I/O 

File 

ID 

Value  of 
ID 

Type 

Close/ 
Retent  ion 

Record | Source! 

Size  I  1 

XXXXXXXXXX 

X 

XXXXX 

XXXXXXXX 

XXX 

XXX 

XXXXX Ixxxxxxl 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Instructions  for  describing  the  file 

specifications  are: 

1)  PROGRAM  ID  -  The  unique  identification  label 
for  the  program.  List  the  programs  in  order 
of  their  IDS. 

2)  I/O  File  use.  I  =  input;  0  =  output;  I/O  = 
input  and  output. 

3)  FILE  ID  -  The  unique  identification  label  for 
the  file.  List  input  files  first,  followed 
by  intermediate  files,  and  then  by  output 
files . 

4)  VALUE  OF  ID  -  External  File  ID. 

5)  TYPE  -  The  type  of  file  is  indicated  by  using 
the  following  abbreviations: 

C  =  Card  P  =  Printer 

T  =  Tape  D  =  Disk 
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CLOSE/RETN  -  The  closing  and  retention 
policies  for  the  file.  Card  and  tape 
retention  periods  are  to  be  given  in  days. 
(Normally  hold  two  backup  cycles  unless  there 
are  special  requirements  for  longer 
retention) . 

The  following  abbreviations  are  used  for 
indicating  the  closing  or  copying  of  a  file: 

C  =  Close 

CW  —  Close  with  no  rewind 

CR  =  Close  with  release 

CL  =  Close  with  lock 

R  =  Remove  at  end  of  job 

7)  RECORD  SIZE  -  Show  record  length  in 
characters,  and  blocking  factor  of  disk  and 
tape  files  as  a  combined  entry  under  Record 
Size . 

8)  SOURCE  -  Indicates  where  the  file  came  from. 

••  Job  Initiation  Instructions.  Describe  in  detail  the 

actions  necessary  on  the  part  of  Production  Control  to 
initiate  the  system.  These  may  include  source  document 
review,  batch  balancing,  deck  setup,  etc.  This  section 
should  be  written  as  a  procedure  and  in  sequential 
steps . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

■  Parameter  Record  Definitions.  The  Parameter  Record 
Definitions  provide  Operations  personnel  with  the 
format  and  content  of  data  control  cards  (including 
data,  balance,  and  options  cards)  that  are  input  to 
programs  that  process  system  jobs.  The  information 
enables  operations  personnel  to  correctly  identify  and 
accurately  modify  cards  as  required.  The  information 
for  parameter  records  is  documented  with  a  brief 
narrative  and  detailed  specifications  of  the  Records, 
a.  Narrat ive .  The  brief  narrative  describes  the 

general  use  of  parameter  cards  in  the  system  and 
the  method  of  communciation  from  the  user. 
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b .  Detailed  Specifications. 
FORMAT: 


PROGRAM 

ID 

‘FIELD  NAME 

DESCRIPTION 

COLUMNS  S 

FROM 

TO 

TOTAL  1 

XXXXXXX 

XXXXXXXXXX 

xxxxxxxxxxxi 

XX 

XX 

XX  1 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Instructions  for  describing  the  parameter 

specifications  are: 

1)  PROGRAM  ID .  The  unique  identification  label 
for  program.  Lists  the  parameter  records  in 
Program-ID  order. 

2)  FIELD  NAME.  The  field  name  for  each  field  on 
the  record. 

3)  DESCRIPTION .  A  brief  description  of  the  data 
required  in  each  field,  the  options 
available,  and  their  meaning.  The  following 
requirements  should  be  observed: 

a)  In  "Description"  column,  give  an 
explanation  of  the  data  required  in  each 
field,  options  available  and  their 
meaning . 

b)  All  constant  data  will  be  enclosed  in 
quotation  marks. 

c)  Indicate  format  of  the  data  required  - 
MMDDYY,  YYMMDD,  etc. 

d)  Indicate  specific  date  to  be  used  - 
current,  last  day  of  month,  last  working 
day  of  month,  etc. 

e)  Indicate  left  or  right  justification  and 
zero  fill,  if  required. 

4)  COLUMNS  FROM/TO /TOTAL.  The  range  of  position 
for  each  field  and  the  number  of  positions 
used  on  the  card  for  each  field. 
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4.  Restart/Rerun  Procedures.  The  Restart /Rerun  Procedures 
must  provide  operations  personnel  with  the  necessary 
information  to  restart  a  system  job  if  a  particular 
program  comes  to  an  abnormal  stop  due  to  hardware 
malfunction.  Software  malfunctions  are  not  within  the 
scope  of  this  specification;  they  are  normally  referred 
to  the  responsible  system  analyst  for  resolution. 
Restart  procedures  are  provided  for  each  application  or 
utility  program  executed  during  system  job  processing. 
Procedures  are  provided  for  each  point  in  each  program 
where  restart  is  possible. 

FORMAT; 


STEP 

NUMBER 

PROGRAM 

IDENTIFICATION 

DESCRIPTION /PROCEDURES 

XX 

XXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

The  instructions  for  describing  restart  and  rerun 
procedures  are: 

a.  STEP  NUMBER .  The  sequential  number  of  each  job 
step  for  which  restart  procedures  are  provided. 

b.  PROGRAM  ID .  The  unique  identification  label  for 
the  program. 

c.  DESCRIPTION/PROCEDURES .  This  column  contains  two 
different  types  of  restart  information: 
Description  and  Procedures.  Description  precedes 
the  Procedure.  Description  describes  the 
production  processing  environment  of  the  job  from 
a  restart  point  of  view.  System  design  and  job 
backup  and  recovery  considerations  relevant  to 
restart  procedures  are  presented. 

Procedures  provide  step-by-step  actions  to  be 
taken  by  the  operator  to  restart  each  program  at 
each  job  step.  Input  for  Job  Restart  Procedures 
can  be  derived  from  the  recovery  part  of  the 
program  specifications.  Information  typically 
contained  in  Procedures  includes: 

1)  Restart  Points  in  the  system. 

2)  Data  files  that  must  be  reloaded  or  deleted. 
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3)  Special  restart  programs  that  must  be 
executed . 

4)  Job  Flow  language  that  must  be  used. 

5)  Special  instructions  that  must  be  entered  by 
the  operator. 

5.  Balancing  Instructions.  The  Balancing  Instructions 
provide  the  necessary  details  to  balance  the  output  of 
a  system,  including  corrective  action  to  be  taken  if 
totals  do  not  balance.  Also  include  an  illustration  of 
the  balance  sheet . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

6.  Report  Distribution.  The  Report  Distribution  provides 
Production  Control  with  the  information  needed  to 
distribute  outputs  of  production  jobs  to  end  users. 
Distribution  control  information  includes  the  type  of 
form  the  output  is  produced  on,  post-production 
preparation  of  the  output,  and  the  identity  and 
location  of  the  recipient. 

FORMAT: 


REPORT  ID 
AND  NAME 

FORM 

ID 

COPIES- 

PREPARATION 

INSTRUCTIONS 

DISTRIBUTION 

xxxxxxxxx 

xxxxxxxxx 

XXXX 

XX 

XXXXXXXXXXXXXX 

XXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXX 1 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Instructions  for  describing  report  output  requirements 

and  distribution  are: 

a.  REPORT  ID  AND  NAME .  The  report  ID  and  the  title 
of  the  output. 

b.  FORM  ID .  The  number  of  the  form  or  stock  on  which 
the  output  is  prepared. 

c .  COPIES .  The  number  of  copies  of  the  output 
produced . 

d.  PREPARATION  INSTRUCTIONS .  The  instructions  to 
Production  Control  personnel  for  handling  and 
preparing  the  output  for  distribution. 
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Some  routine  output  handling  and  preparation  tasks 
are:  deliver  as  is;  decollate;  burst;  trim;  bind; 
with  input;  with  messages;  mark  confidential;  will 
call;  hard  copy;  destroy;  etc. 

DISTRIBUTION .  The  name  of  the  organization  and/or 
location  that  is  the  recipient  of  the  output.  If 
multiple  copies  of  a  report  are  distributed  to 
multiple  recipients,  this  column  must  identify 
each  recipient. 

Off-Site  Transmittals.  Describe  any  requirements  for 
the  transmittal  of  system  data  off-site,  either  to 
off-site  storage,  an  off-line  printer,  or  a  microfiche 
processor . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Job  Control  Language  (JCL).  The  Job  Control  Language 
is  the  means  by  which  jobs  are  described  and  presented 
to  the  computer  system.  This  language  allows  the  user 
to  describe  each  job  as  an  interrelated  set  of  tasks  to 
be  performed.  Both  serial  and  parallel  task  execution 
is  possible. 

Jobs  will  be  accepted  from: 

a)  Online  card  readers. 

b)  Remote  Job  Entry  (RJE)  stations. 

c)  Operator  Display  Terminals  (ODT). 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

E.  Data  Control.  Describe  the  data  entry  instructions  for  Data 
Control.  The  instructions  will  consist  of  a  Data  Submission 
narrative  and  Data  Keying  Instruction  Forms. 

1.  Data  Submission.  The  Data  Submission  narrative 
includes  information  on: 

a.  What  the  source  documents  are,  where  they  are 
from,  and  when  they  will  be  received  by  Data 
Control . 

b.  Whether  the  documents  are  to  be  keypunched  and 
verified . 

c.  When  and  where  the  source  documents  and  cards  are 
to  be  distributed. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DSC  1260-28 
(April  1981) 


DEPARIHENT  OF  THE '  INTER  I  Qa 
BUREAU  OF  LAND  MANAGEffiix' 
NEY-EK'TRV  INSTRUCTlOix'S 


JOB  TITLE- 


PAOE__ 


FORMAT  NAME 


REFORMAT  REQUIRED' 


RECORD  TYPE  _ _ 

INPUT  RECORD  SIZE 


OUTPUT  RECORD 


YES 


SIZE 


FIELD 

INPUT  -  COLUMNS  -  OUTPUT 

UALlDATlOt^S  ^ 

FROM 

THRU 

NUM 

TYPE 

FROM 

THRU 

4 

• 

1 

- 1 - 

j 

CONTACT  NAME  AND  OFFICE  CCDS _ 

CONTACT  TELEPHONE  NUMBER__ 
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2.  Data  Keying  Instructions. 

a.  Guidelines  for  data  entry. 

1)  Show  all  data  items  to  be  entered. 

2)  Cross  reference  each  data  item  to  the 
corresponding  item  on  the  source  document  by 
the  use  of  the  name  field. 

3)  Submit  a  sample  source  document  with  document 
items  circled  along  with  the  filled  out  Key 
Entry  Instruction  Form. 

4)  Submit  the  Request  for  Key  Entry  Services 
with  the  1260-28  Form. 

b.  This  form  should  be  completed  with  the  assistance 

of  the  Key-Entry  Section.  Instructions  for  the 

completion  of  the  Key-Entry  Instruction  Form  (Form 

No.  DSC  1260-28)  are: 

1)  JOB  TITLE .  The  name  of  the  job. 

2)  FORMAT  NAME.  The  key-to-disk  format 
ass igned . 

3)  RECORD  TYPE.  The  record  type  being  keyed. 

4)  INPUT  RECORD  SIZE.  Size  in  characters. 

5)  OUTPUT  RECORD  SIZE.  Size  in  characters. 

6)  FIELD .  Name  of  the  field  being  keyed. 

7)  INPUT-COLUMNS-OUTPUT .  Enter  the  columns  on 
the  source  document,  the  number  of 
characters,  and  the  columns  on  the  keyed 
record . 

8)  VALIDATIONS .  Instructions  on  validations, 
edits,  and  verification. 

9)  CONTACT .  Individual  who  can  answer  questions 
on  data. 

F .  Computer  Operations. 

1 .  Console  Messages.  The  console  messages  provide 

Operations  Personnel  with  descriptions  of  console 
messages  and  the  procedures  for  responding  to  those 
messages.  Messages  generated  by  each  program  executed 
during  the  system  job  processing  are  documented  for 
each  program. 
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FORMAT: 


PROGRAM 

ID 

MESSAGE 

REASON /ACT ION 

XXXXXXX 

XXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXXXXXXXXX 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

Instructions  for  describing  the  console  messages  are: 

a.  PROGRAM  ID .  The  unique  identification  label  for 
the  program.  List  the  programs  in  order  of  their 
IDs . 

b.  MESSAGE .  This  is  the  literal  message  that  will 
appear  to  the  operator  on  the  console.  Only 
messages  requiring  an  operator  response  should  be 
documented.  It  is  to  be  understood  that  any  other 
messages  are  to  be  ignored  by  the  operator. 
Messages  usually  take  one  of  two  forms  -  textual 
or  coded.  Whether  messages  are  in  text  or  code, 
they  generally  require  an  explanation;  this  is  to 
be  provided  in  the  adjacent  description  column. 
Every  effort  should  be  made  to  present  the  message 
precisely  as  it  will  appear  on  the  console. 

Special  attention  should  be  given  to 
capitalization,  punctuation,  and  spacing  of 
messages  when  documenting  them.  The  message 
should  be  enclosed  in  quotes  on  the  form. 

c .  Reason/Action 

1)  REASON .  This  is  an  explanation  of  the  reason 
for  each  message  in  the  message  column. 

There  must  be  a  description  for  each  message; 
blanks  are  not  acceptable. 

2)  ACTION .  This  is  a  list  of  procedural  steps 
to  be  taken  by  the  operator,  in  response  to  a 
message,  to  remedy  the  cause  of  an  abnormal 
stop  in  program  execution.  Action  procedures 
must  be  sufficiently  complete  to  permit  the 
operator  to  remedy  the  cause  of  the  message. 
If  the  action  contents  cannot  satisfy  this 
test,  then  the  message  the  action  applies  to 
does  not  meet  the  criteria  for  being 
documented  in  the  console  messages.  That 
criteria  stipulates  that  only  messages  the 
operator  can  respond  to  are  to  be  documented. 
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2.  Job  Carriage  Tape  Layouts.  The  Job  Carriage  Tape 
Layout  provides  Operations  Personnel  with  the 
information  needed  to  punch  carriage  control  tapes  for 
printer  formatting  of  system  job  outputs. 

The  information  for  job  carriage  tape  layouts  is 
documented  on  the  Job  Carriage  Tape  Layout  Form. 

Instructions  for  the  completion  of  the  Job  Carriage 
Tape  Layout  form  (Form  No.  )  are: 

a.  SYSTEM  NAME.  The  title  of  the  system. 

b.  PROGRAM  ID .  The  unique  identification  label  for 
the  program.  List  the  programs  in  order  of  their 
IDs. 

c.  FILE  ID.  The  identification  of  the  file  from 
which  the  report  is  produced. 

d.  FREQUENCY .  A  statement  of  how  often  the  job  is 
normally  processed.  It  is  usually  expressed  in 
the  number  of  occurrences  per  day,  week,  or  month. 
Occasionally  it  is  expressed  as  "Year  End"  or 
"Quarterly" . 

e.  FORM  NO .  The  form  number  on  which  the  report  is 
printed. 

f.  REPORT  ID  AND  NAME .  The  report  ID  and  name  of  the 
report  produced. 

g.  CHANNEL /line  NUMBER.  A  tabular  schematic  that 
lists  the  tape  channels  and  the  lines  of  the 
output  that  the  functions  controlled  by  the 
channel  apply  to. 

h.  INSTRUCTIONS .  This  tells  the  person  preparing  the 
tape  what  to  do  with  it. 

i.  ALIGNMENT  GUIDE.  Instructions  on  how  to  align  the 
stock  that  will  be  printed  under  the  control  of 
the  carriage  tape. 

j.  COMMENTS .  A  place  for  miscellaneous  statements 
about  the  form  or  job,  or  about  the  tape  if 
pre-defined  components  will  not  accommodate  the 
information . 


117 


DEVELOPMENT  PHASE  -  PROGRAMMING 


OPERATIONS  MANUAL 


Section  9  (Cont.) 

3.  Special  Forms.  The  Special  Forms  provide  Operations 
Personnel  with  specifications  and  procedures  for 
aligning  job  outputs  that  require  precise  character 
placement  on  preprinted  forms  stock.  An  alignment 
template  and  a  finished  form  should  be  included  in  the 
sample.  The  contents  of  this  part  provide  Operations 
Personnel  with  a  convenient  reference  to  the  alignment 
steps  for  each  special  form  that  is  output  during 
system  job  processing. 

FORMS:  Preprinted  or  special  form  stock. 
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Program  Maintenance  Manual 

The  purpose  of  these  procedures  is  to  assist  the  analyst  and 
programmer  in  developing  a  comprehensive  documentation  package 
that  specifies  the  development,  maintenance,  and  operation  of 
each  program.  These  procedures  must  also  provide  the  maintenance 
programmer  with  the  information  necessary  to  understand  the 
programs,  their  operating  environment,  and  their  maintenance 
procedures . 

The  final  form  of  the  documentation,  which  is  generated  during 
the  Initiation  and  Development  Phase  of  the  System  Life  Cycle, 
shall  be  called  a  Program  Maintenance  Manual.  The  contents  of 
one  Program  Maintenance  Manual  shall  describe  one  production  job 
stream,  which  would  usually  include  more  than  one  program. 

A.  Title  Page.  The  first  page  of  every  Program  Maintenance 
Manual  must  be  a  title  page.  The  title  page  identifies  the 
system  and  also  provides  an  area  for  signing  off  as  the 
different  stages  of  development  are  completed. 

The  signature  of  the  responsible  individual  is  required: 

1 .  After  the  Program  Maintenance  Manual  has  been  reviewed 
for  completeness  and  accuracy  during  the  walk  through. 

2.  After  the  program  and  system  testing  has  been 
successfully  completed,  and  it  is  determined  that  the 
documentation  is  consistent  with  the  processing 
requirements . 

3.  When  the  documentation  is  placed  in  the  library  and 
formally  accepted  by  the  Librarian. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

B.  Table  of  Contents.  The  Table  of  Contents  will  contain  a 
list  of  all  documents  associated  with  a  Program  Maintenance 
Manual  and  their  corresponding  page  numbers.  In  the  event 
that  an  item  is  not  required  to  describe  a  particular  job 
stream,  it  should  specify,  in  the  page  column,  NA  for  not 
applicable . 
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Detailed  System  Description 
Detailed  System  Flow  Chart 
System  Logic 
System  Controls 
Computer  Processing  Logic 
Glossary  of  Terms /Abbrev . 


FORMS;  SYSTEM  DOCUMENTATION  (A)  (FORM  NO. 


C .  Introduction 

1 .  Order  for  ADP  Report  Action  (1265).  The  1265  provides 
a  convenient  method  to  document  a  request  of  data 
processing  services:  All  1265s  will  be  maintained  in 
the  Program  Maintenance  Manual. 

2.  Requirements/Feasibility  Study .  The 
Requirements/Feasibility  Study  provides  detailed 
information  for  evaluation  of  the  economic  and 
technical  feasibility  of  a  proposed  new  system  or  major 
modification . 

a.  Requirements  Study.  The  requirements  are  written 
by  the  requestor  to  describe  the  requirements  of  a 
proposed  new  system  or  major  modification  in  the 
requestor's  own  terms. 


120 


DEVELOPMENT  PHASE  -  PROGRAMMING 


PROGRAM  MAINTENANCE  MANUAL 


Section  10  (Cont.) 

b.  Feasibility  Study  (As  Required).  The  Feasibility 
Study  elaborates  on  the  Requirements  Study  and 
presents  the  system  and  its  costs  in  more  detail 
and  in  a  more  technical  manner  by  the  systems 
analys  t . 

3.  System  Narrative .  The  system  narrative  is  written  to 
outline  the  purpose  of  the  system,  the  scope  in  terms 
of  functional  and  organizational  involvement;  and 
authorization  of  the  system. 

System  Description.  The  system  description  consists  of 
a  generalized  functional  description  of  the  new  system 
or  major  modification. 

5.  Functional  Flow  Chart.  The  functional  flow  chart 
graphically  portrays  the  informational  flow  of  the 
system.  All  functions,  processes,  procedures,  and 
organizations  are  identified. 

6.  Integrated  System  Environment  Chart.  The  integrated 
system  environment  chart  shows  existing  or  proposed 
interface  with  all  other  manual  or  machine  systems. 

7 .  Assumptions/Constraints . 

a.  Assumptions .  Those  conditions  that  cannot  be 
supported  by  factual  information. 

b.  Constraints.  Circumstances  or  limitations  upon 
which  the  system  must  depend. 

D .  System. 

1.  Detailed  System  Description.  The  detailed  system 
description  expands  the  general  description  of  the 
system  and  consists  of  an  in-depth  functional  narrative 
of  the  new  system  or  major  modification. 

2.  Detailed  System  Flow  Chart.  The  detailed  system  flow 
chart  expands  the  functional  flow  chart  consisting  of  a 
detailed  graphic  portrayal  of  all  functions,  processes, 
procedures,  and  organizations  of  the  system. 

3.  System  Logic.  System  logic  is  a  description  of  the 
methods  and  procedures  required  by  the  system.  All 
edits,  conditions,  logical  relationships,  techniques, 
etc.,  are  defined.  Graphic  illustrations,  charts, 
formulas,  etc.,  are  used  when  necessary  to  describe  a 
system  requirement. 
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System  Controls .  System  controls  identify  the 
checking,  balancing,  or  other  control  procedures  used 
by  user  organizations  to  maintain  validity  of  the 
system.  The  internal  processing  controls  are  also 
described . 

5.  Computer  Processing  Logic.  Computer  processing  logic 
describes  the  processing  logic  of  the  system.  It 
contains  computer  processing  flow  charts  which  provide 
an  overall  picture  of  the  identification  and 
relationship  of  processing  segments,  sequences,  data 
sets/files/data  bases,  inputs,  and  outputs.  Also 
included  are  program  descriptions /specifications  and 
inter-relationships . 

6-  Glossary  of  Terms/Abbreviations.  The  glossary  of 
terms /abbreviations  are  technical  terms,  words, 
phrases,  and  abbreviations,  which  require  further 
explanation  and  definition. 

E .  Programming . 

Program  Description.  The  program  description  is  a 
narrative  briefly  describing,  in  non-technical  terms, 
the  program's  major  functions,  procedures,  special 
features,  and  equipment  requirements. 

2.  Program  Logic  Flow  Chart .  The  program  logic  flow  chart 
is  a  pictorial  representation  of  the  program.  It  is 
the  diagram  of  operations  and  decisions  along  with  the 
sequence  in  which  they  are  performed  by  a  computer. 

3.  Techniques/Tables .  The  techniques /tables  documentation 
is  used  for  complex  programs  with  specialized 
requirements,  which  are  not  self-explanatory  by 
reference  to  the  program  listing. 

4 .  Input /Output ■ 

a.  System  Input  Requirements .  System  inputs  describe 
each  input  medium  as  to  its  purpose,  function,  and 
relationship  to  the  system.  The  data 
organization,  sorting  sequence,  indexes,  and 
control  fields  are  specified  for  each  input  file. 
Include  copies  of  all  manually  or  mechanically 
prepared  documents  to  be  converted  to  a 
machine-readable  form  for  the  program. 
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b.  System  Output  Requirements .  System  outputs 

describe  each  output  product  as  to  its  purpose, 
function,  and  its  relationship  to  other  output 
supports.  The  data  organization  sorting  sequence, 
indexes,  and  control  fields  are  specified  for  each 
output  file. 

5.  Internal  Files/Data  Sets.  The  internal  files/data  sets 
describe  each  internal  output  file/data  set  with 
respect  to  purpose,  function,  and  its  relationship  to 
other  system  output.  The  data  organization,  sorting 
sequence,  indexes,  and  control  fields  are  specified  for 
each  output  file. 

6.  Program  Controls .  Control  information  is  a  series  of 
explanatory  paragraphs  defining  how  program  controls 
imposed  on  inputs  and/or  outputs  operate.  JCL  read  by 
the  program  is  also  listed. 

7.  Program  Compile/Cross-Reference .  Each  program  is 
documented  with  a  source  program  listing  obtained  from 
the  compilation.  This  is  the  computer  sequential 
organization  of  program  instructions  in  the  source 
language.  The  sections  or  paragraphs  of  the  programs 
are  cross-referenced  to  flow  charts  and  other 
documentation  elements.  Also,  for  each  program,  a 
computer  generated  cross-reference  listing  is  produced 
of  declarations  and  uses  of  all  data-names,  file-names, 
condition-names,  etc. 


F.  Test . 

1.  Test  Data.  Test  data  includes  all  data  used  to  test 
and  debug  each  program  and  the  system.  The  purpose  and 
function  of  the  input  medium  and  its  relationship  to 
the  system  are  described.  All  test  data/files  are 
listed  and  maintained  for  future  use. 

2.  Test  Results.  The  purpose  and  function  of  the  output 
product  and  its  relationship  to  other  output  products 
or  to  other  interfacing  systems  which  it  supports  are 
described.  Include  samples  of  the  output  test  results. 
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Each  production  system  must  provide  for  a  complete  and  clear 
user's  guide.  The  purpose  of  the  user's  guide  is  to  sufficiently 
describe  the  functions  performed  by  the  software  in  non-ADP 
terminology,  such  that  the  user  organization  can  determine  its 
applicability  and  when  and  how  to  use  it.  It  should  serve  as  a 
reference  document  for  preparation  of  input  data  and  parameters 
and  for  interpretation  of  results. 

This  section  will  set  forth  the  procedures  to  be  followed  in 
documenting  a  user's  guide.  The  final  form  of  the  documentation 
described  here  shall  be  called  a  user's  manual.  The  contents  of 
one  user's  manual  shall  describe  one  production  system. 

A.  Title  Page.  The  first  page  of  every  user's  manual  must  be  a 
title  page.  The  title  page  identifies  the  system  and  also 
provides  an  area  for  sign  off. 

The  signature  of  the  responsible  individual  is  required: 

1.  After  the  program  and  system  testing  has  been 
successfully  completed,  and  it  is  determined  that  the 
documentation  is  consistent  with  the  processing 
requirements . 

2.  When  the  system  is  placed  into  a  production  status  and 
the  user's  manual  is  formally  accepted  by  the  user 
organizaton . 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

B.  Table  of  Contents.  The  table  of  contents  will  contain  a 
list  of  all  documents  associated  with  a  user's  manual  and 
their  corresponding  page  numbers.  In  the  event  that  an  item 
is  not  required  to  describe  a  particular  job  stream,  it 
should  specify,  in  the  page  column,  NA  for  not  applicable. 
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Sunmary 


Output  Formats 
Sample  Outputs 
Error  and  Recovery 
File  Query 


Data  Base 

Inputs,  Processing 
and  Outputs 


FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO. 


). 


C .  General  In  format  ion . 

1.  Summary .  Suninarize  the  application  and  general 
functions  of  the  software. 

2.  Environment .  Identify  the  user  organization  and 
computer  center  where  the  software  is  installed 

3.  References .  List  applicable  references,  such  as: 

a.  Project  request  (authorization). 

b.  Previously  published  documents  on  the  project. 

c.  Documentation  concerning  related  projects  and 
software . 

d.  FIPS  publications  and  other  reference  documents 


FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 


D .  App licat ion . 

1 .  Descript  ion .  Describe  when  and  how  the  software  is 
used  and  the  unique  support  provided  to  the  user 
organization.  The  description  should  include: 
a.  Purpose  of  the  software. 
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b.  Capabilities  and  operation  improvements  provided. 

c.  Functions  performed. 

2.  Operation .  Show  the  operating  relationships  of  the 
functions  performed  to  the  organization  that  provides 
input  to  and  receives  output  from  the  software. 

Describe  security  and  privacy  considerations.  Include 
general  charts  and  a  description  of  the  inputs  and 
outputs  shown  on  the  charts. 

3.  Equipment .  Describe  the  equipment  on  which  the 
software  can  be  run. 

4.  Structure .  Show  the  structure  of  the  software  and 
describe  the  role  of  each  component  in  the  operation  of 
the  software. 

5.  Performance .  Describe  the  performance  capabilities  of 
the  software  including,  where  appropriate: 

a.  Quantitative  information  on  inputs,  outputs, 
response  time,  processing  times,  and  error  rates. 

b.  Qualitative  information  about  flexibility  and 
reliability. 

6.  Data  Base.  Describe  all  data  files  in  the  data  base 
that  are  referenced,  supported,  or  kept  current  by  the 
software.  The  description  should  include  the  purpose 
for  which  each  data  file  is  maintained. 

7.  Inputs,  Processing,  and  Outputs .  Describe  the  inputs, 
the  flow  of  data  through  the  processing  cycle,  and  the 
resultant  outputs.  Include  any  applicable 
relationships  among  inputs  or  outputs. 

FORMS: 

SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

SYSTEM  DOCUMENTATION  (B)  (FORM  NO.  ). 

E.  Procedures  and  Requirements .  This  section  should  provide 

information  about  initiation  procedures,  and  preparation  of 
data  and  parameter  inputs  of  the  software.  The  scope, 
quality,  and  logical  arrangement  of  the  information  should 
enable  the  user  to  prepare  required  inputs  and  should 
explain,  in  detail,  the  characteristics  and  meaning  of  the 
outputs.  It  should  also  describe  error,  recovery,  and  file 
query  procedures  and  requirements. 

1.  Init iat ion .  Describe  step-by-step  procedures  required 
to  initiate  processing. 
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2.  Input .  Define  the  requirements  of  preparing  input  data 
and  parameters.  Typical  considerations  are: 

a.  Conditions — e.g.,  personnel  transfer,  out  of 
stock. 

b.  Frequency — e.g.,  periodically,  randomly,  as  a 
function  of  an  operational  situation. 

c.  Origin — e.g..  Personnel  Section,  Inventory 
Control . 

d.  Medium — e.g.,  keyboard,  punched  card,  magnetic  or 
paper  tape. 

e.  Restrictions — e.g.,  priority  and  security 
handling,  limitations  on  what  files  may  be 
accessed  by  this  type  of  transaction. 

f.  Quality  control — e.g.,  instructions  for  checking 
reasonableness  of  input  data,  action  to  be  taken 
when  data  appears  to  be  in  error,  documentation  of 
errors . 

g.  Disposition — e.g.,  instructions  necessary  for 
retention  or  release  of  all  data  files  received, 
other  recipients  of  the  inputs. 

3.  Input  Formats.  Provide  the  layout  forms  used  in  the 
initial  preparation  program  data  and  parameter  inputs. 
Explain  each  entry,  and  reference  it  to  the  sample 
form.  Include  a  description  of  the  grammatical  rules 
and  conventions  used  to  prepare  input,  such  as: 

a.  Length — e.g.,  characters /line  ,  characters /item . 

b.  Format — e.g.,  left  justified. 

c.  Labels — e.g.,  tags  or  identifiers. 

d.  Sequence — e.g.,  the  order  and  placement  of  items 
in  the  input . 

e.  Punctuation — e.g.,  spacing  and  use  of  symbols 
(virgule,  asterisk,  character  combinations,  etc.) 
to  denote  start  and  end  of  input,  of  lines,  of 
data  groups,  etc. 

f.  Combination — e.g.,  rules  forbidding  use  of  groups 
of  particular  characters  or  combinations  of 
parameters  in  an  input . 

g.  Vocabulary — e.g.,  an  appendix  which  lists  the 
allowable  character  combinations  or  codes  that 
must  be  used  to  identify  or  compose  input  items. 

h.  Omissions  and  Repeats — e.g.,  indicate  those 
elements  of  input  that  are  optional  or  may  be 
repeated . 


127 


DEVELOPMENT  PHASE  -  PROGRAMMING 


USER  MANUAL 


Section  11  (Cont.) 

i.  Controls — e.g.,  header  or  trailer  control  data. 
Sample  Inputs.  Provide  specimens  of  each  complete 
input  form.  Include; 

a.  Control  or  header — e.g.,  entries  that  denote  the 
input  class  or  type,  date/time,  origin,  and 
instruction  codes  to  the  software. 

b.  Text — e.g.,  subsections  of  the  input  representing 
data  for  operational  files  or  that  request 
parameters  for  an  information  retrieval  program. 

c.  Trailer — e.g.,  control  data  denoting  the  end  of 
input  and  any  additional  control  data. 

d.  Omissions — e.g.,  indicate  those  classes  or  types 
of  input  that  may  be  omitted  or  are  optional . 

e.  Repeats — e.g.,  indicate  those  positions  of  the 
input  that  may  be  repeated. 

5.  Output .  Describe  the  requirements  relevant  to  each 
output.  Typical  considerations  are: 

a.  Use — e.g.,  by  whom  and  for  what. 

b.  Frequency — e.g.,  weekly,  periodically,  or  on 
demand . 

c.  Variations — e.g.,  modifications  that  are  available 
to  the  basic  output. 

d.  Destination- — e.g.,  computer  area  or  remote 
terminal . 

e.  Medium — e.g.,  printout,  CRT,  tape,  cards. 

f.  Quality  control — e.g.,  instructions  for 
identification,  reasonableness  checks,  editing, 
and  error  correction. 

g.  Disposition — e.g.,  instructions  necessary  for 
retention  or  release,  distribution,  transmission, 
priority,  and  security  handling. 

6.  Output  Formats.  Provide  a  layout  of  each  output. 
Explanations  should  be  keyed  to  particular  parts  of  the 
format  illustrated.  Include; 

a.  Header — e.g.,  title,  identification,  date,  number 
of  output  parts. 

b.  Body — e.g.,  information  that  appears  in  the  body 
or  text  of  the  output,  columnar  headings  in 
tabular  displays,  and  record  layouts  in  machine 
readable  outputs.  Note  which  items  may  be  omitted 
or  repeated. 

c.  Trailer — e.g.,  summary  totals,  trailer  labels. 

7.  Sample  Outputs.  Provide  a  sample  of  each  type  of 
output.  For  each  item  on  a  sample,  include: 
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a.  Definition — e.g.,  the  meaning  and  use  of  each 
information  variable. 

b.  Source — e.g.,  the  item  extracted  from  a  specific 
input,  from  a  data  base  file,  or  calculated  by 
software . 

c.  Characteristics — e.g.,  the  presence  or  absence  of 
the  item  under  certain  conditions  of  the  output 
generation,  range  of  values,  unit  of  measure. 

8.  Error  and  Recovery.  List  error  codes  or  conditions 
generated  by  the  software  and  corrective  action  to  be 
taken  by  the  user.  Indicate  procedures  to  be  followed 
by  the  user  to  ensure  that  any  restart  and  recovery 
capability  can  be  used. 

9.  File  Query.  Prepare  this  paragraph  for  software  with  a 
file  query  retrieval  capability.  Include  detailed 
instructions  necessary  for  initiation,  preparation,  and 
processing  of  a  query  applicable  to  the  data  base. 
Describe  the  query  capabilities,  forms,  commands  used, 
and  control  instructions  required. 

If  the  software  is  queried  through  a  terminal ,  provide 
instructions  for  terminal  operators.  Describe  terminal 
set-up  or  connect  procedures,  data  or  parameter  input 
procedures,  and  control  instructions.  Reference 
related  materials  describing  query  capabilities, 
languages,  installation  conventions  and  procedures, 
program  aids,  etc. 

FORMS:  SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 
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DEVELOPMENT  PHASE 


INTRODUCTION 


Section  0. 

Introduction 

During  the  Test  Stage  of  development,  the  software  is  tested  and 
related  documentation  reviewed.  The  software  and  documentation 
are  evaluated  in  terms  of  readiness  for  implementation. 

Testing  computer  software  consists  of  static  and  system  tests. 
The  static,  or  unit,  test  is  the  testing  of  individual  programs. 
The  System  Test  is  the  testing  of  a  production  job  stream,  which 
would  usually  include  a  series  of  programs  in  their  processing 
sequence . 
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DEVELOPMENT  PHASE  -  TEST 


PROJECT  TEAM  ADMINISTRATION 


Section  1. 

Project  Team  Administration 


A.  Upon  completion  of  the  Programming  Phase,  the  responsible 
project  team  memberCs)  will  prepare  a  Test  Plan  including 
appropriate  elements  from  the  list  below: 

1.  Review  processing  logic  of  source  program  listing(s). 

2.  Prepare  program  test  data. 

3.  Execute  program  tests  and  evaluate  test  results  to 
assure  that  the  program  performs  according  to 
specifications . 

4.  Compile  static  test  documentation. 

5.  Prepare  system  test  data. 

6.  Prepare  system  test  schedule. 

7.  Establish  system  performance  criteria. 

8.  Execute  the  system  test  and  evaluate  test  results  to 
assure  that  the  system  performs  according  to 
specifications . 

9.  Review  the  Users,  Operations,  and  Program  Maintenance 
Manuals  to  assure  that  the  documentation  is  consistent 
with  the  processing  requirements. 

10.  Compile  system  test  documentation. 

B.  Walk-Through .  The  members  of  the  walk-through  team  will 
vary  in  accordance  with  the  material  being  reviewed.  The 
walk-through  is  chaired  by  the  Project  Coordinator  and 
conducted  by  the  individual  responsible  for  the  material. 

The  purpose  of  the  walk-through  is  to  determine  if  the 
program(s)  and  system  perform  according  to  specifications, 
and  to  assure  that  the  required  documentation  is  complete 
and  consistent  with  the  processing  requirements. 

The  Test  Phase  must  be  approved  by  the  responsible 
individuals  and  management  before  the  Operation  Phase  can  be 
initialized . 
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STATIC  TEST 


Section  2, 


Static  Test . 


When  a  program  has  been  coded,  desk  checked,  and  a  syntax  free 
compile  obtained,  static  testing  will  be  conducted  to  assure  the 
program  functions  according  to  specifications. 

Since  system  testing  can  be  an  expensive  operation,  involving 
numerous  people  and  considerable  machine  time,  it  is  essential 
that  every  effort  be  made  to  detect  errors  during  static  testing 
of  the  individual  programs. 

Static  testing  is  the  responsibility  of  the  programmer.  Adequate 
test  data  should  be  prepared  to  test  the  main-line  process  of  the 
program  and  all  exceptions.  Develop  predetermined  output  which 
will  facilitate  checkout.  Minimize  hands-on  testing  and  costly 
compilation  and  retesting  time  by  performing  extensive  "desk 
checking"  prior  to  the  next  test  of  a  program. 
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PRE-TEST  DESK  CHECK 


Section  3. 

Pre-Test  Desk  Check 


The  objective  of  this  step  is  to  achieve  maximum  benefit  from  the 
first  program  test  by  reducing  the  likelihood  of  abnormal 
termination  and  checking  that  the  code  does  satisfy  program 
specifications . 

Incomplete  desk  checking  may  result  in  excessive  use  of  machine 
time  during  checkout,  increased  programmer  effort  to  correct 
errors,  and  a  greater  chance  of  exceeding  the  scheduled 
completion  date. 

Particular  areas  for  review  are: 

A.  Initialization  Logic. 


1 . 

Initializing  working  storage  fields 

2. 

Opening  files. 

3. 

Processing  of  file  control  records. 

4. 

Loading  tables. 

B. 

Termination  Logic. 

1. 

Closing  files. 

2. 

Displaying  end-of-job  messages. 

3. 

Writing  the  file  control  records. 

4. 

Writing  stored  records  or  tables. 

C. 

File- 

-Handling  Logic. 

1. 

Sequence  checking. 

2. 

File  matching. 

3. 

Control  break  testing. 

4. 

Initial  read  routines. 

5. 

End-of-file  processing. 

D. 

Report  Generation. 

1. 

Page  overflow  handling. 

2. 

Control-break  processing. 

3. 

Totaling  logic. 

4. 

End-of-job  output. 
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DEVELOPMENT  PHASE  -  TEST 


PRE-TEST  DESK  CHECK 


Section  3  (Cont.) 

E .  Processing  Logic. 

1.  AND/OR  decisions. 

2.  Validation  of  all  raw  input. 

3.  All  first  time  or  one  time  logic. 

4.  Looping. 

5.  Division  by  zero. 

6.  Subscripting. 
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DEVELOPMENT  PHASE  -  TEST 


PROGRAM  TEST  DATA 


Section  4. 

Program  Test  Data 

Preliminary  testing  of  a  computer  program  should  utilize  small, 
representative  test-data  files  so  as  to  avoid  long,  expensive 
test  runs  on  large  "LIVE"  data  files.  Frequently,  test  files  can 
be  created  by  extracting  a  few  records  from  an  existing  file. 

The  objective  of  test  data  preparation  is  to  set  up  sample 
transactions,  test  files,  and/or  data  bases  that  will  adequately 
test  a  program  or  sub-program.  Creation  of  comprehensive  test 
data  can  be  a  time  consuming  task,  but  it  is  imperative  to  the 
successful  implementation  of  a  system.  Assuming  that  any  portion 
of  a  program  does  not  require  testing  can  lead  to  costly 
failures . 

A.  Timing.  Preparation  of  test  data  should  begin  innnediately 
after  the  coding  while  the  processing  requirements  are  fresh 
in  one ' s  mind . 

B.  Test  Data  Sources.  Existing  test  data  sources  can  be  used 
if  all  necessary  test  combinations  are  present,  and  the 
volume  of  test  data  is  not  excessive. 

1.  Test  data  sources  are; 

a.  Copies  of  production  files. 

b.  Selections  from  production  files  by  some  utility. 

c.  Output  from  another  program  in  the  system. 

d.  A  test  data  generator. 

e.  Card  to  tape/disk  utilities. 

f.  Unique  test  file  creation  programs. 

g.  On  line  input. 

h.  Card  input. 

C.  Test  Data  Combinations.  Specific  attention  should  be  paid 
to  testing  the  following  conditions; 

1.  All  combinations  of  file  match /mismatch . 

2.  All  combinations  of  missing  or  variable  occurrence 
records  within  a  file. 

3.  All  error  conditions. 

4.  All  combinations  of  EOF  situations. 

5.  All  variations  of  run  control  parameters. 

6.  Extreme  ranges  of  field  values. 

It  is  usually  necessary  to  create  more  than  one  input  test 
file  to  test  these  conditions. 

FORMS;  -eondition  Table  ) . 
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PROGRAM  TEST 


Section  5. 

Program  Test 

All  types  of  program  input  must  be  tested,  all  types  of  program 
output  must  be  generated,  and  every  line  of  program  code  must  be 
executed . 

The  intent  and  expected  result  of  each  test  input  must  be 
documented  and  retained.  This  is  particularly  important  for 
one-line  program  testing.  It  is  usually  helpful  to  note  the 
intent  within  the  test  data  itself,  by  using  a  character  field 
that  is  not  significant  to  processing  control. 

Those  programs  which  generate  output  files  to  be  used  as  input  to 
the  following  cycle  must  be  tested  through  two  or  more  cycles  to 
assure  that  those  files  cycle  correctly;  i.e.,  the  file  which  is 
output  from  one  cycle  is  acceptable  as  input  to  the  next  cycle 
and  that  valid  outputs  are  created  from  it. 
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DEVELOPMENT  PHASE  -  TEST 


PROGRAM  TEST  DOCUMENTATION 


Section  6. 

Program  Test  Documentation 

A-  Test  Data.  The  test  data  documentation  includes  all  data 
used  to  test  and  debug  each  program.  Describe  each  input 
medium  as  to  its  purpose,  function,  and  relationship  to  the 
program.  The  data  organization,  sorting  sequence,  indexes, 
and  control  fields  are  specified  for  each  test  file. 

B.  Test  Resul ts .  Describe  each  output  product  from  the  test 
run  as  to  its  purpose,  function,  and  relationship  to  other 
output  products  or  to  other  programs.  The  data 
organization,  sorting  sequence,  indexes,  and  control  fields 
are  specified  for  each  output  file. 

All  test  data/files  are  listed  and  maintained  for  future  use. 
Include  samples  of  the  output  test  results. 

FORMS: 

SYSTEM  DOCUMENTATION  (A)  (FORM  NO,  ). 

DATA  FILE  LAYOUT  SHEET  ~  COBOL, 

DATA  FILE  LAYOUT  SHEET  -  REX. 

80  COLUMN  LAYOUT  SHEET  (FORM  1265-9). 
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SYSTEM  TEST 


Section  7. 
System  Test 


When  all  programs  within  a  system  have  been  individually  tested, 
a  system  test  plan  developed,  and  system  test  data  created, 
coordinated  testing  of  all  system  components  can  be  conducted. 

Although  the  various  programs  have  already  passed  static  testing, 
the  system  test  must  again  test  all  program  logic,  all  inputs, 
outputs,  and  cycling  capability  and  determine  the  validity  of  all 
interfaces  within  the  system. 

The  system  test  must  very  closely  simulate  actual  production 
conditions.  All  users  of  the  system  should  be  extensively 
involved  in  this  phase.  A  portion  of  the  test  data  should  be 
provided  by  user  departments.  All  controls  and  reports  produced 
in  this  phase  must  be  thoroughly  reviewed  by  the  appropriate  user 
groups . 
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SYSTEM  TEST  DATA 


Section  8. 

System  Test  Data 

Test  Data  includes  all  data  that  will  be  used  in  the  Test  Run. 

If  feasible,  use  all  input  normally  processed.  Often,  it  is  not 
feasible  to  use  all  input  to  test  a  system.  Control  is  extremely 
difficult  when  large  volumes  of  data  are  provided  in  an  initial 
run;  thus  only  selected  data  representing  all  input  types  will  be 
used . 

A  test  data  file  is  to  be  prepared  for  each  master,  table,  and 
input  file  used  in  the  system.  Test  data  files  must  contain  at 
least  one  example  of  each  condition  that  can  be  encountered  in 
the  system.  As  conditions  within  a  program  change,  the  test  data 
files  must  be  updated  in  order  to  remain  complete.  Test  data 
files  must  include  all  error  conditions,  all  I/O  functions,  check 
point  and  restart  procedures,  no-data  conditions,  and  any 
additional  special  requirements. 

The  systems  analyst  must  make  certain  that  the  test  data  includes 
all  possible  criteria,  conditions,  and  combinations  in  order  to 
effectively  ascertain  the  system's  performance. 
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TEST  SCHEDULE 


Section  9. 
Test  Schedule 


A  test  schedule  must  be  prepared  which  specifies  how  testing  will 
progress  and  when  it  will  be  completed.  A  System  Test  Schedule 
Form  will  be  used  for  establishing  the  sequence  of  operations  for 
perfotming  complete  systems  test. 

Instructions  for  the  completion  of  the  System  Test  Schedule  Form 
(FORM  NO.  )  are: 

Step .  All  operations  in  the  test  are  assigned  a  number  to 
indicate  sequence. 

B.  Test .  All  test  cases  are  assigned  an  identification  number. 

C.  Program.  This  provides  a  cross-reference  to  the  program 
number  pertaining  to  this  test. 

D.  Input  Required.  The  inputs  required  are  listed  here  by 
input  name  and/or  reference  number.  Indicate  whether  the 
input  contains  "live"  or  "dummied"  data. 

E.  Files  Required.  The  files  required  are  listed  here  by  file 
name  or  reference  number  and  the  source  of  the  file  must  be 


identified.  Indicate 
"dummied"  data. 

whether 

the 

file 

contains 

"live"  or 

Results.  The  desired 

results 

for 

each 

step  must 

be 

referenced . 
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PERFORMANCE  CRITERIA 


Section  10. 
Performance  Criteria 


The  new  system's  procedures  must  be  measured  to  insure  that  they 
are  operating  effectively, 

A  new  system  must  be  tested  in  parallel  with  the  previous  system 
or  manual  procedures,  if  they  exist.  The  results  of  the  two 
systems  or  procedures  must  then  be  compared.  The  accuracy  of  the 
previous  systems  or  manual  procedures  must  be  measured  against 
the  accuracy  of  the  new  design. 

The  performance  criteria  must  specify  acceptable  limits  or  error 
ratios.  It  can  be  anticipated  that  some  discrepancy  will  occur, 
particularly  in  a  test  run.  The  performance  criteria  serves  as  a 
quality  control  specification  for  all  conditions  in  the  system. 
These  must  include  control,  processing,  and  output  test  criteria. 
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TEST  PROCEDURES 


Section  11. 

Test  Procedures 


The  specific  operations  and  procedures  to  be  followed  and  their 
corresponding  sequence  is  outlined  in  the  diagram  on  the 
following  pages.  The  system  testing  procedures  described  must  be 
followed  to  insure  that  the  system  will  operate  efficiently  with 
minimum  problems.  Each  organizational  unit  must  perform  its 
assigned  task  in  the  sequence  specified. 
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SYSTEM  TEST  DOCUMENTATION 


Section  12. 

System  Test  Documentation 


A.  Test  Data.  The  test  data  documentation  includes  all  data 
used  to  test  and  debug  the  system.  Describe  each  input 
medium  as  to  its  purpose,  function,  and  relationship  to  the 
system.  The  data  organization,  sorting  sequence,  indexes, 
and  control  fields  are  specified  for  each  test  file. 

B.  Test  Results.  Describe  each  output  product  from  the  test 
run  as  to  its  purpose,  function,  and  its  relationship  to 
other  output  products  or  to  other  interfacing  systems  which 
it  supports.  The  data  organization,  sorting  sequence, 
indexes,  and  control  fields  are  specified  for  each  output 
file . 

All  test  data/files  are  listed  and  maintained  for  future  use. 
Include  samples  of  the  output  test  results. 

FORMS: 

SYSTEM  DOCUMENTATION  (A)  (FORM  NO.  ). 

DATA  FILE  LAYOUT  SHEET  (COBOL). 

DATA  FILE  LAYOUT  SHEET  (REX). 

80  COLUMN  LAYOUT  SHEET  (FORM  1260-9). 
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OPERATION  PHASE 


INTRODUCTION 


Section  0. 
Introduct ion 


During  the  Operation  Phase,  the  software  and  documentation  are 
placed  into  a  production  status,  maintained,  evaluated,  and 
changed  as  additional  requirements  are  identified. 
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OPERATION  PHASE 


INTRODUCTION 


Section  0  (Cont.) 

Data  processing  is  directed  to  three  methods: 

A.  Oti~line  Usage.  Terminals  located  at  the  user's  work  area 
are  in  direct  communication  with  the  computer,  with  data 
processing  being  accomplished  on  a  computer  time-sharing 
basis.  Control  of  the  system,  programs,  input  data,  and 
output  data  is  with  the  user,  with  little  or  no  intervention 
by  Computer  Operations  or  Production  Control. 

Remote  Job  Entry  (RJE).  As  with  on-line  usage,  RJE  involves 
terminals  at  the  user's  work  area  in  direct  communication 
with  the  computer.  In  most  cases  RJE  requires  the  input  of 
data  to  a  file,  with  processing  deferred  until  computer 
resources  are  available.  Processing  results  are  then 
transmitted  to  the  remote  terminal  (if  terminal  has  output 
capabilities),  or  are  generated  at  the  computer  location  for 
distribution  to  the  user. 

C.  Production  (Batch).  Production  processing  is  the  recurring 
processing  of  relatively  large  requirements,  generally 
during  those  periods  when  on-line  usage  of  computer 
resources  is  low  or  non-existent.  This  type  of  processing 
usually  involves  the  Key  Entry  unit  converting  data  from 
user  documents  to  the  computer.  Production  Control  is 
responsibile  for  scheduling  and  controlling  the  input, 
processing,  and  output  for  distribution  to  the  user. 
Scheduling  of  production  runs  are  dictated  by  the  recurring 
requirements  of  users,  generally  on  a  period  (or  time) 
basis . 
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PROJECT  TEAM  ADMINISTRATION 


Section  1. 

Project  Team  Administration 


A.  Upon  completion  of  the  Test  Phase,  the  responsible  project 
team  member(s)  will: 

1.  Transfer  the  system/program  and  its  documentation  to 
production  status. 

2.  Establish  processing  priority. 

3.  Establish  processing  schedule. 

4.  Review  and  establish  production  control  preprocessing 

and  postprocessing  job  management. 

5.  Review  and  establish  computer  processing  job 

management . 

6.  Review  and  establish  data  entry  job  management. 

7.  Review  and  establish  system/ program  recovery  file 
management . 

B.  Walk-Through .  The  members  of  the  walk-through  team  will 
vary  in  accordance  with  the  material  being  reviewed.  The 
walk-through  is  chaired  by  the  Project  Coordinator  and 
conducted  by  the  individual  responsible  for  the  performance 
of  the  activity. 

The  purpose  of  the  walk-through  is  to  review  the  established 
processing  environment,  and  determine  if  the  priority, 
schedule,  job  management,  and  recovery  procedures  are 
consistent  with  the  system  processing  requirements. 

The  Operation  Phase  must  be  approved  by  the  responsible 
individuals  and  management  before  the  system  can  be 
processed  as  a  production  system. 
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System/Program  Transfer 

When  the  Test  Phase  is  completed  and  approved  by  the  responsible 
individuals  and  management,  the  system/program  and  its 
documentation  are  transfered  to  a  production  status. 

The  Project  Coordinator  will  schedule  a  formal  meeting  with 
Production  Control  to  turn  over  the  items  of  documentation  and 
provide  the  information  necessary  to  run  the  system  in 
production.  Changes  to  existing  operational  programs  will 
require  only  information  pertinent  to  the  changes. 

A.  System  Trans fer .  A  System  Transfer  form  must  be  used  to 
transfer  a  new  system  from  the  User  Group  Work  System  to  the 
Production  System.  The  transfer  form  is  initiated  by  the 
programmer  and  approved  by  the  Project  Coordinator. 

Instructions  for  the  completion  of  the  System  Transfer  Form 
(FORM  NO.  )  are: 

1.  User  Group.  Use  the  user  code. 

2.  System.  The  name  of  the  system. 

3.  Request  Date.  Date  the  Operation  Section  is  requested 
to  transfer  the  software  to  production. 

4.  Transfer  Date.  Date  the  Operation  Section  transfers 
the  software  to  production. 

5.  Project  Coordinator.  The  name  of  the  Project 
Coordinator  authorizing  the  transfer. 

6 .  Work  System  Identification. 

a.  User  Code.  The  user  group. 

b.  Software  Name.  The  identification  of  the  software 
on  the  User  Work  System. 

7  .  Production  System  Identification. 

a.  User  Code.  The  user  group. 

b.  Software  Name.  The  identification  of  the  software 
on  the  Production  System. 

8.  Version  Date.  Software  compilation  date. 

B.  Program  Transfer.  The  Program  Transfer  form  previously  used 
to  transfer  the  production  software  to  the  User  Group  Work 
System  must  also  be  used  to  transfer  the  modified  software 
back  to  production.  The  transfer  form  is  initiated  by  the 
programmer  and  approved  by  the  Project  Coordinator. 
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Instructions  for  the  completion  of  the  return  portion  of  the 
Program  Transfer  Form  (FORM  NO.  )  are: 

1.  Request  Date.  Date  the  Operation  Section  is  requested 
to  return  the  software  to  production. 

2.  Return  Date.  Date  the  Operation  Section  transfers  the 
software  to  production. 

3.  Project  Coordinator .  The  name  of  the  Project 
Coordinator  authorizing  the  transfer  to  production. 

4 .  Work  System  Identification. 

a.  User  Code.  The  user  group. 

b.  Software  Name.  The  identification  of  the  software 
on  the  User  Work  System. 

5 .  Production  System  Identification. 

a.  User  Code.  The  user  group. 

b.  Software  Name.  The  identification  of  the  software 
on  the  Production  System. 

6.  Version  Date.  Software  compilation  date. 

The  Program  Transfer  form  must  also  indicate  if  there  are 
changes  to  the  documentation  which  supports  the  production 
software . 

C.  Documentation  Turnover .  The  documentation  required  to 

support  a  new  system  or  revised  software  in  a  production 
environment  must  be  turned  over  to  the  individuals 
responsible  for  the  processing  and  maintenance  of  the 
computer  system  before  the  system  can  be  processed  as 
production . 

1.  Program  Maintenance  Manual .  This  manual  is  placed  in  a 
program  library  which  will  serve  as  the  sole  repository 
for  all  production  systems.  A  librarian  must  establish 
a  checkout  procedure  to  be  observed  when  any  item  is 
removed  from  the  library. 

2.  Operation  Manual .  This  manual  is  placed  in  the 
Production  Control  Library. 

3.  User's  Manual.  This  manual  is  placed  in  the  User 
Organization  Library.  A  copy  of  the  User's  Manual  will 
also  be  maintained  in  the  Program  Library. 
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Work  Load  Priorities 


A.  General  Policy.  The  operating  objective  of  the  BLM  Computer 
Center  is  to  support  the  information  processing  requirements 
of  the  Bureau  in  the  most  effective  and  efficient  manner 
possible  within  the  constraints  of  manpower  and  computer 
resources.  While  it  is  our  goal  to  provide  good  and 
reasonable  service  to  all  system  users,  the  work  load  and 
user  expectations  will  sometimes  exceed  the  capability  of 
the  system  to  respond  in  a  timely  and/or  satisfactory 
manner.  This  problem  is  largely  the  result  of  improper 
scheduling  and  distribution  of  work  load  across  the  entire 
period  of  system  availability.  For  example,  the  computer  is 
often  saturated  with  jobs  during  the  day  shift  but  is 
usually  underutilized  or  idle  on  the  night  shifts.  Of 
course,  management  directed  priority  processing  during  the 
day  shift  and/or  peak  period  production  requirements  which 
cannot  be  rescheduled  also  aggravate  the  problem. 

In  order  to  alleviate  this  situation,  the  following  policy 
guidelines  will  be  used  to  govern  system  utilization  and 
allocation  among  the  various  users  and  functions: 

1.  The  job  mix  within  the  computer  will  be  controlled 
primarily  by  the  automatic  scheduling  modules  (.MSCAN). 

2.  Production  requirements  which  can  be  satisfied  with 
overnight  turnaround  will  be  processed  on  the  night 
shifts. 

3.  Jobs  which  require  large  amounts  of  computer  resources 
will  normally  be  run  on  the  night  shift  unless  approved 
for  day-shift  processing  by  management. 

4.  Computer  program  development  and  maintenance  activities 
will  be  allowed  to  process  on  the  day  shift.  Jobs 
which  involve  only  the  compilation  of  a  program  will  be 
assigned  a  higher  urgency  by  the  system  scheduler  to 
assure  quick  turnaround 

5.  On-line  systems,  such  as  the  Mining  Claim  Recordation 
System,  will  maintain  a  high  priority,  both  in  schedule 
and  service,  unless  overridden  by  management  in  special 
circumstances . 


151 


OPERATION  PHASE 


WORK  LOAD  PRIORITIES 


Section  3  (Cont . ) 

6.  All  production  applications  will  be  assigned  a  relative 
priority  by  management.  When  scheduling  or  processing 
conflicts  develop  between  production  requirements,  such 
jobs  will  be  processed  in  order,  according  to  their 
priority . 

7.  Utilization  of  the  H66/80  computer  system  will  be  in 
accordance  with  the  schedule  and  operational  support 
priorities  defined  in  Section  II,  paragraphs  A.  and  B. , 
of  the  Operating  Plan. 

8.  The  system  scheduler  modules  (.MSCAN)  will  include  a 
special  production  job  queue  for  each  state  to  enable 
the  State  Offices  to  prioritize  their  production  jobs. 
That  priority  scheme  will  apply  only  for  ordering  jobs 
within  the  queue;  once  a  job  is  selected  from  the  queue 
for  processing,  it  will  be  treated  like  any  other 
production  job  in  the  system. 

9.  Scheduled  production  jobs  which  fall  behind  schedule 
due  to  program  or  equipment  failure  will  be  given 
preferential  treatment  and  be  allowed  to  process  on  the 
day  shift  if  computer  resources  are  available. 

10.  System  development  and  maintenance  programmers  and 
analysts  will  review  all  existing  and  future  production 
job  streams  to  ensure  proper  allocation  and  efficient 
use  of  system  resources.  This  will  include  making  the 
necessary  JCL  entries  for  scheduling  the  job  to  process 
on  the  night  shifts  when  appropriate. 

11.  The  Chief,  Office  of  Data  Systems,  will  be  the  final 
authority  in  resolving  conflicts  in  scheduling  and 
utilization  of  the  H66/80  computer  system.  Such 
conflicts  will  be  resolved  in  accordance  with  the 
guidelines  contained  in  the  Operating  Plan.  '  Requests 
for  significant  deviation  from,  or  revision  of,  the 
Operating  Plan  will  be  submitted  through  the  Chief, 
Division  of  Data  Operations,  to  the  Chief,  Office  of 
Data  Systems,  and  the  Service  Center  Director. 
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B.  Schedule  and  Priority  of  Production  Applications. 

Attachment  A  of  the  Operating  Plan  contains  a  list  of 
current  production  applications,  the  periods  during  which 
they  will  normally  be  scheduled,  the  conditions  under  which 
they  will  be  granted  priority  consideration,  and  the 
relative  order  in  which  requirements  will  be  serviced  in  the 
event  of  scheduling  and/or  processing  conflicts.  User 
requests  for  deviation  from  the  guidelines  in  Exhibit  A  must 
be  prepared  and  submitted  to  the  Chief,  Division  of  Computer 
Operations  (D-250)  for  consideration  and  action  (See  Exhibit 
B  of  the  Operating  Plan). 
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Section  4. 

Processing  Schedule 

Reference  the  Bureau's  Operating  Plan  for  scheduling  of  the 
computer . 


OPERATION  PHASE 


PREPROCESSING  AND  POSTPROCESSING  JOB  MANAGEMENT 


Section  5. 

Preprocessing  and  Postprocessing  Job  Management 

These  procedures  are  related  specifically  to  Production  (Batch) 
processing,  the  documentation  required,  and  control  exercised. 

A.  Production  Control  Organization.  The  Production  Control 
Unit  is  a  part  of  the  Division  of  Computer  Operations. 
Within  the  unit,  personnel  have  control  responsibility  for 
assigned  systems,  or  a  group  of  systems,  or  magnetic  tape 
library  documentation  maintenance. 

B.  Production  Control  Documentation.  The  Operations  Manual 
developed  during  the  Programming  Stage  of  development 
provides  instructions  to  be  used  by  Production  Control  in 
scheduling,  setting  up,  and  running  a  given  job.  From  this 
documentation  Production  Control  will: 

1.  Review  the  Job  Control  Language  (JCL)  Listing.  In  the 
JCL  Listing,  parameter  data  should  be  highlighted  to 
define  data  subject  to  change. 

2.  Prepare  a  CRUN.  This  listing  is  to  portray  the 
sequence  of  steps  in  the  processing  of  the  system  and 
contains : 

Control  Information. 

Input  Information. 

Processing  Information. 


Out 

put  Information 

a . 

Output  files  with 

media  distinction  (cards, 

magnetic  tape,  or 

disk) . 

b. 

Reel  number . 

c . 

File  ID. 

d. 

File  disposition. 

e . 

File  retention. 

f . 

Comments  relative 

to  the  processing. 

g. 

Print  requirements 

and  report  distribution. 

All  processing  documentation  will  be  maintained  in  a 
System  Processing  Manual. 

C.  Preprocessing  Procedures.  The  following  procedures  will  be 
performed  by  the  Production  Control  personnel; 

1.  At  the  scheduled  run  time  for  a  group  of  programs  to  be 
processed,  obtain  the  pertinent  JCL  and  the  system 
processing  manual . 
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2.  Change  parameters  as  required. 

3.  Obtain  copy  of  CRUN  for  scheduled  run. 

4.  Record  magnetic  tape  reel  numbers  on  the  input  area 
from  last  run  information  and  Tape  Library  Listing. 

5.  Forward  to  Computer  Operations  for  processing, 

D-  Postprocessing  Procedures.  The  following  procedures  are 
performed  by  the  Production  Control  personnel: 

1.  Check  balancing  controls  as  specified  by  the  Operations 
Manual . 

2.  Review  JCL  printout  and  CRUN  listing  to  insure  job  was 
run  with  no  unresolved  problems. 

3.  Check  reel  numbers. 

4.  Advise  user  that  reports  are  completed  and  distribute. 

5.  Record  information  of  tape  reel  numbers  for  input  to 
Tape  Library  System. 

6.  Place  Control  Reports,  Job  Run  Listings,  and  CRUN 
Request  in  the  System  Processing  Manual  . 

Persons  responsible  for  preprocessing  and  postprocessing  job 
management  should  be  able  to  respond  to  any  inquiry 
concerning  the  processing  status  of  a  job.  Coordination 
between  scheduling  and  job  management  functions  plays  a 
major  role  in  satisfactory  job  status  inquiries  and 
operating  efficiency. 

Also,  all  requirements  for  security  and  privacy,  as  related 
to  files,  programs,  and  other  data  while  under  Production 
Control's  jurisdiction,  will  be  met. 

(Reference  "Security",  Chapter  8  of  this  manual). 
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Section  6. 

Computer  Processing  Job  Management 

Procedures  are  related  specifically  to  Production  (Batch) 
Processing,  the  documentation  required,  and  controls  exercised. 

All  jobs  will  be  submitted  with  instructions  which  completely 
detail  for  the  computer  operator  what  is  to  be  done  for  executing 
the  production  request. 

A.  Processing  Procedures.  The  following  procedures  are 
performed  by  the  Computer  Operator: 

1.  Obtain  required  tapes  from  library  and  process  the  job 
per  the  CRUN. 

2.  Attach  tape  labels  to  output  tape  reels  as  defined  by 
Production  Control. 

3.  Record  output  tape  reel  numbers  in  space  provided. 

4.  At  completion  of  run,  make  distribution  of  material  as 
fol lows : 

a.  Production  Control  -  CRUN  Listing 

-  Printer  Output 

-  Job  Run  Listing 

b.  Library  -  Input  Tapes 

~  Output  Tapes 

All  jobs  entering  and  leaving  Computer  Operations  will  be 
under  complete  accounting  and  location  control  at  all  times. 
The  operator's  primary  concern  is  maintaining  a  consistently 
high  level  of  computer  utilization,  while  finishing  every 
job  scheduled  into  the  jobstream.  Jobs  programmatically 
removed  under  exception  control  and  referred  to  an  analyst 
for  remedial  action  are  to  be  rescheduled  as  the  analyst  is 
notified . 
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Data  Entry  Job  Management 

A.  General .  Data  Entry  is  the  process  of  converting  data  from 
a  written  or  printed  form  to  a  form  that  is  recognizable  by 
computing  equipment.  Data  to  be  converted  is  usually 
contained  on  documents  that  are  used  in  normal  conduct  of 
business.  For  a  high  degree  of  data  integrity,  the  source 
or  original  documents  should  be  used  as  the  basis  for  data 
entry . 

B.  Methods  of  Data  Entry .  Most  data  entry  in  a  business  data 
processing  environment  is  accomplished  by  activation  of  keys 
(typewriter-like  keyboard).  There  are  two  general  methods: 

1.  Centralized  organization  -  user  documents  are  submitted 
to  a  central  group  where  data  is  converted  to  punched 
cards,  magnetic  tape,  or  magnetic  disks  for  subsequent 
entry  into  computing  equipment. 

2.  Decentralized  remote  -  data  is  entered  into  a  terminal 
for  direct  transmittal  to  computer  equipment  via  a 
communications  linkage.  Terminals  are  located  in  user 
areas  with  user  responsibility  for  control, 
verification,  and  editing  as  defined  by  system  user 
manual . 

Both  methods  of  Data  Entry  are  used  within  the  Bureau  of 
Land  Management.  The  procedures  outlined  in  this  section  of 
the  ADP  Procedures  pertain  specifically  to  the  centralized 
Data  Entry  Unit,  Procedures  for  terminal  entry  from  remote 
locations  are  defined  in  System  User  Manuals. 

C .  Procedures . 

1.  New  Job  Acceptance .  New  or  revised  systems,  requiring 
data  conversion  services  by  the  Data  Entry  Unit,  are 
defined  and  approved  during  the  Design/Specifications 
stage  of  development. 

The  Request  for  Key  Entry  Services,  Data  Submission 
Narrative,  Data  Keying  Instructions,  and  Card/Record 
Layout  forms  are  provided  in  the  Operation's  Manual. 
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2.  Data  Entry  Control. 

a.  Batches .  To  maintain  control  of  documents 
submitted  to  the  Data  Entry  Unit,  users  assign  a 
batch  number,  as  required,  to  a  batch  of  the  same 
documents.  Each  batch  must  be  numbered 
consecutively  and  the  date  and  acceptable  control 
amount  noted.  This  unique  number  will  be  logged 
in  a  logbook  upon  receipt  of  the  documents  and 
will  be  logged  out  upon  release  of  the  batch. 

b.  Data  Entry  Schedule.  Recurring  system  jobs  are 
accomplished  on  a  scheduled  basis  consistent  with 
user  requirements  and  overall  schedule  of 
preparation,  process,  and  report  generation. 
Periodic  and  one  time  jobs  are  scheduled  based 
upon  priority  and  resource  availability. 

c.  Data  Verification.  Data  will  be  verified  as 
required  by  systems  requirements  as  defined  in  the 
Data  Keying  Instructions. 

d.  Production  Statistics.  Statistics  of  key  entry 
and  verification  by  each  operator  for  each  system 
job  will  be  maintained. 
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Sys tem/Program  Recovery  File  Management 

A.  General .  The  Division  of  Computer  Operations  will  provide 
for  the  reprocessing  of  data  by  maintaining  a  backup  of 
systems  software,  programs,  and  data  files  and  data  base 
programs  and  files.  The  need  for  a  backup  plan  is  dictated 
by  malfunctions  of  equipment,  software,  utilities,  and  other 
factors.  While  it  is  possible  to  maintain  a  backup  for 
reprocessing  in  a  majority  of  cases,  a  complete  backup  to 
provide  for  all  situations,  for  extended  periods,  is  not 
feasible.  Users  must  also  be  aware  of  their 
responsibilities  in  maintaining  backup  and  restoration.  Any 
unique  backup  requirements  beyond  the  scope  of  these 
procedures  should  be  reviewed  with  the  User  Support  Unit. 

B .  On-Line  User  Backup. 

1.  General .  User  files  resident  on  disk  packs  will  be 
backed  up  and  retained  as  described  below.  Files 
include:  Source  and  Object  Program  Files,  Data  Files, 
Job  Control  Files,  and  Transaction  Files  supporting 
Data  Base  Systems.  Files  related  to  Data  Base  Systems 
(other  than  Transaction  Files)  will  not  be  backed  up  as 
described.  For  Data  Base  File  backup,  see  "F"  below. 

2.  Backup .  Files  are  backed  up  in  Computer  Operations  on 
a  periodic  and  daily  basis. 

a.  Periodic .  Periodically  (not  to  exceed  60  days), 
and  dependent  upon  file  state  (i.e.,  gaps  or 
checkerboarding)  disk  packs  for  each  job  family 
will  be  copied,  serially,  to  another  disk  pack. 

The  copied  disk  will  be  retained  as  a  backup  until 
the  next  disk  copy  is  performed.  The  disk  created 
will  be  used  in  operation. 

b.  Daily .  At  days  end,  files  that  have  been  updated 
during  the  current  work  week  will  be  copied  to 
magnetic  tape  and  the  tape  retained  for  five  (5) 
days.  The  tape  created  on  the  last  day  of  the 
work  week  will  be  retained  for  forty-five  (45) 
days . 
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3.  Limitations . 

a.  Files  must  be  properly  named  by  the  user;  i.e., 
user  code  appended  by  file  type: 

S  =  Source  Program  File 
0  =  Object  Program  File 
D  =  Data  File 
J  =  Job  Control  File 

b.  Only  those  files  having  a  date  change  will  be 
copied  to  tape  for  backup.  Three  dates  are 
maintained  within  the  directory  entry  for  each 
file:  (1)  access  date,  (2)  creation  date,  and  (3) 
update  date.  Dates  are  changed  as  follows: 

all  dates  initialized  -  any  file  created 

-  source,  Job  Control 
access  date  changed  -  data  or  source  read 

-  object  executed 

-  Job  Control  started 

-  data  file  altered  via 
program 

update  date  changed  -  data  file  altered  via 

program 

If  a  file  is  copied  and/or  the  name  changed,  dates  are 
not  affected. 

C.  System  Software  Backup.  Disks  containing  systems  software 
(compilers,  etc.)  are  copied  when  the  software  is  revised 
and  retained  for  three  backup  periods  in  the  Production 
Control  Library. 

D .  Production  Program  Backup. 

1.  Source  and  object  programs  are  copied  weekly  to 
magnetic  tape  and  retained  for  three  backup  periods  in 
the  Production  Control  Library. 

2.  The  magnetic  tape  produced  at  the  end  of  the  fiscal 
year  will  be  retained  in  Production  Control  Library  for 
three  (3)  years. 

3.  Source  programs  copied  to  magnetic  tape  at  the  end  of 
the  fiscal  year  are  retained  for  one  (1)  year  at  an 
off-site  location. 
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E.  Production  Data  File  Backup.  Unique  data  file  back  up  and 

retention  are  defined  during  the  Design/Specification  Stage 

of  development  and  are  recorded  in  the  Operations  Manual 

documentation.  Standard  backup  and  retention  are: 

1.  Daily .  Copy  all  updated  files  to  tape,  retain  tape  for 
seven  (7)  days  in  Production  Control  Library. 

2.  Weekly.  Copy  all  updated  files  to  tape,  retain  tape 
for  thirty  (3)  days  in  Production  Control  Library. 

3.  Month ly .  The  tape  created  from  the  daily  copy  at  the 
end  of  the  month  will  be  retained  for  one  (1)  year  in 
the  Production  Control  Library. 

4.  Annual  (fiscal  year).  The  tape  created  from  the  daily 
copy  at  the  end  of  the  fiscal  year  will  be  retained  for 
seven  (7)  years  in  the  Production  Control  Library. 

F .  Data  Base. 

1.  General .  Data  base  creation,  maintenance,  and 
processing  is  the  responsibility  of  users  utilizing 
remote  terminals.  Backup  procedures  and  retention  of 
transaction  data  files,  data  base  file,  data  base 
software,  and  Job  Control  are  as  described  below: 

2.  Transaction  Data  Files.  All  transactions  will  be 
backed  up  on  a  daily  basis  provided  they  are  on  disk 
and  have  proper  identification.  See  B.  above  for 
backup  and  retention  procedures . 

3.  Data  Base  File.  The  project  manager  has  the 
responsibility  of  generating-  a  backup  to  magnetic  tape 
of  Data  Base  File.  Generally,  this  is  accomplished 
when  the  accumulated  transaction  update  time  is  equal 
to  or  greater  than  the  data  base  dump  (copy)  time. 

(Reference  "Disaster  Recovery  ,  Chapter  9  of  this  manual). 
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Section  0. 
Introduction 


The  Office  of  Data  Systems  Security  Officer  is  responsible  for 
the  implementation  of  the  security  program  outlined  here.  All 
employees  should  be  aware  of  appropriate  security  measures  and 
techniques  to  provide  an  adequate  degree  of  security.  Additional 
information  on  security  procedures  of  automated  information 
systems  is  contained  in  Section  1264,  "Phases  Approach  to 
Security",  of  the  BLM  Manual. 


Security  Risk  Assessment 


Information  Management  Practices 
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Security  Risk  Assessment 


A.  Introduction.  All  records  maintained  by  the  Bureau  must  be 
necessary  and  relevant.  The  level  of  security  needed  to 
support  privacy  data  and  other  records  depends  on  the  use 
which  is  made  of  the  data,  uses  others  could  make  of  the 
data,  and  the  harm  that  could  result  if  the  data  is  misused. 
Additionally,  security  needs  are  dependent  upon  the 
environment  in  which  the  computer  operates.  The  assessment 
of  the  security  risk  must  take  into  account  the 
administrative,  technical,  and  physical  environments  in 
which  the  system  operates  and  which  will  become  a  part  of 
the  overall  security  action  plan.  Authorization  for  access 
to  records  containing  personnel  data  must  be  held  to  an 
absolute  minimum. 

B.  Scope .  A  quantitative  risk  assessment  will  produce  the 
following  benefits: 

1.  Objective  of  the  security  program  will  be  related  to 
the  mission. 

2.  Quantitative  guidance  on  the  amount  of  resources  which 
is  reasonable  to  expend  on  each  security  measure. 

3.  Guidance  in  applying  security  considerations  to  things 
such  as  site  selection,  building  design,  hardware 
configurations  and  procurements,  software  systems,  and 
internal  controls. 

4.  Generated  criteria  for  designing  and  evaluating 
contingency  plans  for  back~up  operation,  recovery  from 
disaster,  and  dealing  with  emergencies. 

5.  Generated  security  policy  which  identifies  what  is  to 
be  protected,  which  threats  are  significant,  and  who 
shall  be  responsible  for  execution,  review,  and 
reporting  of  the  security  program. 

As  outlined  in  Chapter  1.3  of  FIPS  PUB  31,  and  defined 
below,  a  quantitative  risk  assessment  will  be  performed  with 
documented  evidence  of  such  performance  available  for 
review. 

C.  Risk  Analysis.  In  order  to  develop  a  viable  security 
program  a  complete  risk  analysis  must  be  performed.  The 
following  topics  are  to  be  considered,  along  with  others  as 
may  be  applicable: 
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1.  Loss  Potential  Estimate.  Dollar  amounts  must  be 

identified  on  the  loss  of  the  critical  aspects  of  the 
ADP  facility  based  on  the  following; 

a .  Physical  destruction  or  theft  of  tangible  assets . 

Costs  necessary  to  replace  and  costs  due  to 
delayed  processing.  Includes  such  things  as  the 
building,  special  equipment,  ADP  hardware, 
supplies  and  materials,  and  office  equipment. 

b.  Loss  of  data  or  program  files.  Costs  necessary  to 
reconstruct  and  costs  due  to  delayed  processing. 

c.  Theft  of  information.  May  be  intangible  and 
difficult  to  quantify  as  no  destruction  is 
involved.  Would  vary  among  types  of  data  stolen. 

d.  Delayed  processing.  Depends  on  the  type  of  data 
system  delayed  and  for  how  long.  Each  system 
should  be  analyzed  for  its  '‘no  loss'”  delay  time, 
after  which  a  cost  could  be  assessed. 

D.  Threat  Analysis.  The  probability  of  loss  to  ADP  property 
and  capital  equipment  is  met  by  analyzing  the  following 
threats: 

1.  Supporting  utility  hazards  such  as:  power  failure,  air 
conditioning  failure,  or  communication  failure. 

2.  Unauthorized  access  including;  compromising  emanations, 
tampering,  internal  theft  or  misuse,  or  intruders  or 
vandals . 

3.  Natural  disasters  such  as:  floods,  earthquakes,  or 
windstorms . 

4.  Fire,  either  arson  or  caused  by  other  circumstances 
including  smoke  damage. 

5.  ADP  hardware  failure. 

General  information  about  the  probability  of  occurrence  and 
common  sense  are  used  in  developing  estimates.  Help  in 
conducting  threat  analysis  should  be  solicited  from  sources 
who  have  expertise  in  the  above  areas;  i.e.,  fire 
department,  building  manager/engineers,  hardware  vendors. 

E.  Annual  Loss  Expectancy .  By  combining  the  value  of  potential 
loss  with  the  probability  of  loss,  an  estimate  of  the  annual 
loss  expectancy  is  developed.  This  expectancy  will  pinpoint 
areas  of  significant  threats  and  assist  in  determining  where 
the  most  security  for  each  dollar  spent  can  be  realized. 
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F.  Selecting  Remedial  Measures.  By  use  of  the  annual  loss 
expectancy,  the  implementation  of  security  measures  that 
best  suit  the  needs  of  the  Division  can  be  realized.  These 
measures  can  take  the  following  forms; 

1.  Alter  the  environment,  reducing  probability  of 
occurrence . 

2.  Erect  barriers  to  ward  off  threats. 

3.  Improve  procedures,  closing  any  gaps  in  controls. 

4.  Early  detection  of  harmful  situations. 

5.  Develop  contingency  plans. 

G.  Implementation.  The  following  outline  can  be  used  in 
implementing  an  ADP  security  program. 

1.  A  plan  consisting  of  detailed  task  descriptions,  a 
budget,  schedule,  and  responsibility  assignments  should 
be  made  up. 

2.  A  preliminary  risk  analysis  should  be  performed  to 
identify  major  problem  areas. 

3.  Implement  "quick  fix"  measures  which  will  correct  those 
major  problem  areas  uncovered. 

4.  Perform  and  document  a  detailed  risk  analysis.  A 
thorough  review  and  full  coordination  and  approval  from 
the  staff  must  be  received.  Users  of  the  systems  must 
be  involved. 

5.  Develop  action  plans,  complete  with  budget,  schedules, 
contingency,  training,  indoctrination,  test  and  audit 
plans . 

6.  Implement  the  approved  action  plans. 

7.  Annually  review  the  risk  analysis  for  changes  that 
occurred  due  to  the  action  plan  implementation  and 
system  changes.  Update  both  the  documented  risk 
analysis  and  the  action  plan. 
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Physical  Security 

A.  Introduction.  Physical  security  is  the  process  of 
permitting  access  to  the  ADP  facility  to  authorized  persons 
while  denying  access  to  those  unauthorized.  It  entails  the 
roles  of  people,  the  criticallity  of  specific  areas,  and  the 
time  of  day.  The  physical  protection  plan  should  establish 
go/no-go  criteria  for  all  combinations  of  the  above  roles 
and  provide  realistic  measures  to  implement  them. 

Physical  security  measures  are  designed  to  provide 
protection  against  intentional  or  overt  external  acts  to  the 
division's  data. 

In  development  of  the  plan,  a  systematic  and  comprehensive 
analysis  of  the  following  must  be  taken: 

1.  Threats  to  which  the  facility  is  exposed. 

2.  Physical  characteristics  of  the  facility. 

3.  Organization  and  mission  of  the  facility. 

The  goal  of  the  plan  is  to  achieve  an  optimum  level  of 
protection;  i.e.,  neither  inadequate  to  achieve  stated 
objectives  nor  overly  burdensom  and  expensive.  In  other 
words,  the  security  implemented  must  match  the  degree  of 
security  required. 

The  following  topics  may  be  used  in  the  creation  of  a 
physical  security  plan: 

B.  Determining  Requirements.  The  following  topics  should  be 
addressed  in  evaluating  protection  requirements: 

1.  Potential  threat  to  the  facility  from  outsiders 
including: 

a.  Common  criminals. 

b.  Activists. 

c.  Espionage  agents. 

d.  Vandals. 

2.  Define  and  tabulate  control  areas  within  the  facility. 
Some  areas  which  should  be  included  are: 

a.  Entrances  and  lobbies. 

b.  Loading  area. 

c.  Areas  within  the  building  that  contain  non-ADP 
personnel  and  their  proximity  to  the  ADP  facility. 
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d.  ADP  facility. 

e.  Input/Output  control  areas. 

f.  Data  conversion  areas. 

g.  Tape  library. 

h.  Prograiraning/Analysis  areas. 

i.  Utility  rooms  (Air  conditioning,  power,  UPS 
areas ) . 

3.  Evaluate  current  security  measures  already  in  place  and 
determine  the  state  of  current  practices. 

With  the  above  evaluations,  specific  areas  where 
remedial  measures  are  needed,  and  the  selection  of 
measures  which  need  to  be  implemented,  can  be 
formalized. 

C.  Audit .  A  review  of  the  overall  physical  security  program 
must  be  established  to: 

1.  Evaluate  security  controls  for  the  ADP  facility. 

2.  Provide  management  with  a  tool  to  improve  and  update 
its  security  program. 

3.  Provide  incentive  to  employees  and  management  to 
maintain  a  strong  interest  and  a  viable  security 
program. 

4.  Highlight  areas  subject  to  vulnerability. 

D.  Scheduled  Audit.  Annually,  a  major  evaluation  of  the  AD? 
facility  should  be  undertaken  to  insure  that  the  Physical 
Security  Plan  is  current  and  relevant. 

E.  Unscheduled  Audit.  As  determined  necessary,  an  unscheduled 
and  unannounced  review  should  be  undertaken  to  insure  that 
all  activities  are  responding  to  established  security 
procedures.  This  review  will  not  be  held  in  conjuction  with 
the  scheduled  annual  review. 


F.  Audit  Report.  Upon  completion  of  a  review,  a  report  that 
includes  the  following  will  be  completed: 


1 . 

Executive  summary. 

2. 

Description  of  the 

evaluation . 

3. 

Detailed  report  of 

observations 

4. 

Conclusions . 

5. 

Recommendat ions . 

6. 

Supportive  documentation. 
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7.  Distribution  instructions. 

A  follow-up  review  of  the  recommendations  should  be 
undertaken  to  insure  that  action  is  or  has  been  initiated. 

G.  Disaster  Recovery.  Reference  "Disaster  Recovery",  Chapter  9 
of  this  Guide. 
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Information  Management  Practices 

A.  Introduction .  Information  management  is  those  techniques 
and  procedures  used  to  control  operations  on  information  in 
accomplishing  the  Division's  objectives.  It  does  not  extend 
to  essential  managerial  determination  of  the  need  for  any 
uses  of  information  related  to  the  Division's  mission. 
Information  management  includes: 

1.  Data  collection,  validation,  and  transformation. 

2.  Information  processing  or  handling. 

3.  Record  keeping. 

4.  Information  control,  display,  and  presentation. 

5.  Standardization  of  information  management  operations. 

The  effective  application  of  these  techniques  and  procedures 
will  contribute  to  the  Privacy  Act  objectives  of  maintaining 
accurate,  timely,  and  complete  data. 

Information  management  security  practices  are  designed  to 
provide  protection  against  accidental  or  unintentional 
damage  to  files  or  against  overt  internal  acts  to  the 
Division's  data. 

An  examination  of  current  practices  against  the  guidelines 
presented  below  will  determine  whether  modifications  or 
enhancements  are  needed: 

B.  Assignment  of  Responsibility.  The  following 
responsibilities  are  assigned; 

1.  The  ADP  Security  Officer  is  responsible  for  examination 
of  installation  practices  in  storage,  use,  and 
processing  of  personal  data,  including  the  use  of 
physical  security  measures,  information  management 
practices,  and  computer  system  access  controls.  Both 
internal  uses  and  the  authorized  external  transfer  of 
data  are  considered  with  any  risks  reported  and 
documented . 

2.  An  assigned  individual  will  be  responsible  during  each 
processing  shift,  insuring  that  the  facility  is 
adequately  manned  and  all  policies  on  security  are 
enforced . 
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3.  All  employees  engaged  in  handling  and  processing  of 
personal  data  must  adhere  to  established  codes  of 
conduct . 

C.  Handling  of  Personal  Data.  The  following  are  facets 

relating  to  personal  data  handling  that  will  be  implemented: 

1.  Preparation  of  a  procedures  handbook  which  details 
precautions  to  be  used  and  obligations  of  personnel 
during  the  handling  of  personal  data. 

2.  Labeling  of  all  recording  media  which  contain  personal 
data . 

3.  Storage  of  personal  data  under  lock  and  key  when  not  in 
use . 

4.  Printing  warnings  on  all  printouts  v^ich  contain 
personal  data. 

5.  Color  coding  of  all  trays,  reels,  covers,  etc.,  which 
contain  personal  data. 

6.  Record  all  categories  of  personal  data  contained  in 
computer-generated  reports  for  compliance  with 
identification  requirements. 

7.  Control  of  intermediate  products  which  contain  personal 
data . 

8.  Maintain  up-to-date  hard  copy  authorization  of  all 
individuals  authorized  access  to  personal  data. 

9.  Maintain  an  up-to-date  hard  copy  data  dictionary  which 
lists  a  complete  inventory  of  all  data  files  within  the 
Division  containing  personal  data. 

D.  Maintenance  of  Records.  Tracing  the  disposition  of  personal 

data  will  be  accomplished  by: 

1.  Establishing  procedures  for  maintaining  correct, 
current  accounting  of  all  new  personal  data  being 
entered . 

2.  Logging  each  transfer  of  each  storage  media  containing 
personal  data  to  or  from  the  facility. 

3.  Maintaining  log  books  at  terminals  that  are  used  in 
accessing  personal  data  by  system  users. 

E.  Data  Processing  Practices.  The  following  practices  pertain 

to  data  processing. 

1 .  Using  control  numbers  to  account  for  personal  data  upon 
receipt  and  during  input,  storage,  and  processing. 
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2.  Verifying  the  accuracy  of  personal  data  acquisition  and 
entry  methods  employed. 

3.  Taking  both  regular  and  unscheduled  inventories  of  all 
tape  and  disk  storage  media  to  ensure  accurate 
accounting  for  all  personal  data. 

4.  Using  carefully  designed  backup  procedures  for  personal 
data.  A  copy  of  this  data  will  be  kept  at  an  off-site 
location  if  its  maintenance  is  required  by  law. 
(Reference  "Disaster  Recovery",  Chapter  9  of  this 
Guide) . 

5.  Creating  records  retention  time  table  covering  all 
personal  data  storing,  as  a  minimum,  the  data  type,  the 
retention  period,  and  the  authority  responsible  for 
making  the  retention  decision. 

6.  Following  any  computer  failure,  institute  a  checking 
procedure  to  check  for  inaccuracies  in  personal  data 
which  resulted  from  that  failure. 

7.  Examining  files  created  from  personal  data  files  to 
ensure  they  cannot  be  used  to  regenerate  personal  data. 
Establish  a  formal  process  for  determining  and 
certifying  that  such  created  files  are  releasable. 

8.  Information  concerning  an  individual  should  not  be  able 
to  be  traced  when  data  is  being  aggregated  or 
manipulated.  Steps  should  be  taken  so  that,  in 
inference,  deduction,  or  derivation,  processes  can  be 
used  to  recover  personal  data. 

F.  Programming  Practices.  The  following  practices  pertain  to 

programming: 

1.  All  programming  development  and  modification  which 
affects  personal  data  must  be  independently  checked  by 
a  second  programmer  who  follows  procedural  requirements 
which  have  been  developed  by  a  responsible  supervisor. 

2.  Current  programs  which  process  or  access  personal  data 
must  be  inventoried  on  a  periodic  basis  to  verify  their 
authorized  usage  . 

3.  All  operating  systems  changes  that  involve  software 
security  require  strict  control  and  written 
authorization . 

4.  Program  Design.  Five  major  areas  of  programming  design 
can  significantly  contribute  to  overall  security 
practices.  they  are: 
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a.  Audit  trails.  Inclusion  of  audit  trails  should 
make  it  possible  to  determine  the  status  of  any 
given  piece  of  data  at  any  point  in  time . 

b.  Test  plan.  The  development  of  a  saturation  test 
plan  should  include  improbable,  illegal,  or 
impossible  input. 

c .  Program  change.  Programs  must  be  designed  in  such 
a  way  that  future  changes  are  simplified.  All 
changes  should  be  authorized ,  approved ,  and 
documented  to  insure  control  is  maintained. 

d.  Data  record  control .  A  wide  range  of  checks  is 
possible,  including  keypunch  verification, 
computer  matching  against  pre-determined  values, 
self-checking  digits,  and  control  fields. 

e.  Quantitative  controls.  These  controls  should  be 
installed,  where  feasible,  during  the  design 
phase.  They  include  such  things  as  control 
totals,  run-to-run  counts,  trailer  records,  and 
verification  of  output  and  input  record  counts. 

The  need  for  these  types  of  controls  should  be 
determined  by  the  risk  analysis.  A  high  risk  and  valid 
application,  which  consumes  large  amounts  of  ADP 
resources,  should  receive  a  great  deal  of  attention. 

G.  Procedural  Auditing.  When  appropriate,  an  independent  audit 
should  be  performed  to  examine  current  established 
procedures  and  methods  of  insuring  that  these  procedures  are 
being  followed.  The  following  points  should  be  considered: 

1.  Personnel  performing  audits  must  be  independent  of 
those  responsible  for  compliance. 

2.  Independent  auditors  can  be  utilized  at  irregular 
intervals  to  provide  similar  assurances. 

3.  Completed  audit  reports  will  be  maintained  for 
inspection  and  assistance  in  tracing  compromises  of 
confidentiality . 
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Computer  System  Security  Controls 

System-based  security  methods  are  an  expansion  and  addition  to 
physical  security  measures  and  information  management  practices. 
They  include; 

*  User  Identification  Procedures. 

*  Access  Auditing  to  track  activity. 

*  System  mechanisms  to  control  data  access. 

Some  details  are  described  below: 

A.  User  Identification.  Some  method  of  identifying  each 

individual  allowed  to  use  a  system  is  a  necessary  step  in 
safeguarding  data.  The  three  basic  categories  of  methods 
that  can  be  utilized  in  establishing  identity  are: 

*  Something  a  person  knows . 

*  Something  a  person  has. 

*  Something  a  person  is. 

The  first  category  includes  such  things  as  passwords, 
combinations  to  locks,  or  a  series  of  facts  from  an 
individual's  personal  background. 

The  second  category  includes  badges,  cards  with 
machine-readable  information,  and  keys  to  locks. 

The  third  category  consists  of  characteristics,  such  as  a 
person's  appearance,  fingerprints,  hand  geometry,  voice,  or 
signature . 

Portions  of  one  or  more  of  these  categories  may  be 
implemented  as  deemed  necessary  by  the  security  risk 
analysis  and  the  physical  security  plan. 

Passwords  are  perhaps  the  most  widely  used  technique  for 
identifying  and  granting  access  to  a  specific  system.  Some 
considerations  in  use  of  passwords  are: 

1.  They  should  be  attributable  to  an  individual;  i.e., 
each  individual  should  have  his  own  password, 
especially  in  the  case  of  personal  data  files. 

2.  They  should  be  easily  remembered,  but  not  based  upon  a 
person's  name  or  personnel  dates. 

3.  They  should  be  changed  frequently,  and  at  random 
intervals,  as  well  as  when  compromise  is  known  or 
suspected . 
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B.  Access  Auditing.  Access  auditing  is  the  ability  to  account 
for  WHO  has  access  to  WHAT  data.  The  mechanisms  used  for 
controls,  known  as  audit  trails,  are  designed  to  list  all 
system  activity,  data  accesses,  unusual  activity,  etc. 

These  controls  are  usually  built  into  an  application  system. 

C.  System  Access  Control.  System  access  controls  serve  the 
function  of  limiting  the  user,  once  having  gained  access  to 
the  system,  from  reading,  altering,  or  destroying  any  data 
they  wish . 

Lists  or  classes  of  users  are  set  up  to  insure  they  are 
limited  to  the  types  of  activity  performed,  or  to  limit  the 
data  they  can  access.  Either  of  these  methods,  or  a 
combination  of  the  two,  can  be  utilized  to  insure  that  only 
data  activity  occurs. 


176 


ADP  PROCEDURES 


DISASTER  RECOVERY 


CHAPTER  9 


Section 


★ 

Introduction 

0 

* 

Data  and  Program  Back-Up 

1 

* 

Off-Premises  Storage 

2 

* 

Action  Plan 

3 

177 


DISASTER  RECOVERY 


INTRODUCTION 


Section  0. 
Introduction 


Disaster  recovery  provides  the  data,  software,  hardware,  and 
personnel  needed  to  produce  the  essential  output  of  the  Division 
of  ADP  if  the  computer  center  has  been  rendered  inoperative  due 
to  causes  such  as  power  loss,  flood,  fire,  sabotage,  explosion, 
etc.  The  importance  of  the  information  produced  by  the  Division 
of  ADP  and  the  large  number  of  people  affected  by  the  provided 
services,  such  as  payroll,  make  clear  the  vital  nature  of  a 
disaster  recovery  procedure. 


The  Chief,  Office  of  Data  Systems,  has  the  primary  responsibility 
and  authority  for  the  constant  state  of  readiness  for  the 
disaster  recovery  action  plan,  and  the  implementation  of  the  plan 
when  required.  The  Chief,  Division  of  Computer  Operations,  has 
the  responsibility,  as  delegated  by  the  Office  Chief,  for  prompt 
execution  of  the  plan.  The  Security  Officer  has  the 
responsibility  of  timely,  on-the-scene  security  monitoring  and 
control,  including  advising  the  Chief,  Division  of  Computer 
Operations,  of  any  necessary  adjustments  to  security  as  needed 
for  implementation.  Every  ADP  employee  is  responsible  for 
participation  in  disaster  recovery  as  needed. 
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Section  1. 

Data  and  Program  Back-Up 

A.  Operations .  All  files  essential  to  disaster  recovery  will 
be  copied  as  specified  in  the  "System/Program  Recovery  File 
Management"  section  of  the  Operation  Phase.  (Reference 
Chapter  7,  Section  8  of  this  Guide.) 

A  list  of  the  program  IDs  that  are  processed  each  day  will 
be  printed  daily.  Six  generations  will  be  retained. 

B.  Software .  Prepare  a  test  plan  for  initialization  of  the 
back-up  computer. 

C.  Production  Control.  Additional  up-to-date  copies  of  the 
Operations  Manuals  will  be  provided  for  back-up. 

D.  Schedu ling .  A  disaster  standby  priority  list  of  all 
production  jobs  (and  related  programs)  will  be  prepared, 
indicating  the  highest  priority  and  continuing  in  descending 
sequence.  One  week's  work  (six  days),  according  to 
agreed-upon  available  time  and  schedules  at  the  back-up 
computer,  will  be  prepared. 

A  special  National  Emergency  Disaster  Standby  priority  list 
will  be  prepared,  utilizing  specifications  furnished  by  the 
Division  of  ADP  Security  Officer. 

E.  Disaster  Recovery  Staff.  A  Disaster  Recovery  Staff  will  be 
made  up  of  the  following  personnel,  or  their  predetermined 
alternates  if  the  prime  members  are  missing  at  the  time  of  a 
disaster : 

*  Chief,  Branch  of  Computer  Operations. 

*  Supervisor,  Operations  Section. 

*  Supervisor,  Production  Control  Section. 

*  Supervisor,  Sof tware/Telecoramunicat ions . 

The  Disaster  Recovery  Staff  at  all  times  will  be  under  the 
direct  supervision  of  the  D-200  Office  Chief.  The  staff 
head  will  act  as  the  delegate  of  the  Office  Chief  in  prompt 
execution  of  all  requirements.  The  Security  Officer  will 
control,  monitor,  and  provide  for  implementation  of 
adjustments  to  security. 
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Section  1  (Cont . ) 

This  staff  will  prepare: 

1.  A  Personnel  Recovery  List,  identifying  who  is  to  do 
what  in  the  Action  Plan,  including  mobilization  data. 
The  list  will  include  key  vendor  and  back-up  personnel . 

2.  An  Emergency  Notification  List  of  their  own  names, 
office  telephone  numbers,  home  addresses,  and  home 
telephone  numbers,  with  the  same  data  listed  for  their 
alternates . 

A  copy  of  this  list  will  be: 

a.  Posted  at  the  Computer  Center. 

b .  Kept  by  each  operator . 

c.  Furnished  to  the  Federal  Center  Security  Force  and 
to  the  Federal  Center  Fire  Department . 

d.  Kept  by  each  staff  member  and  alternate. 

e.  Retained  by  the  appropriate  office  at  the  back-up 
f acil ity . 

f.  Stored  at  the  off-premise  storage  location. 

3.  A  definition  of  a  disaster  that  would  trigger  the  use 
of  the  Emergency  Notification  List  and  the  subsequent 
activation  of  the  Action  Plan.  The  definition  would  be 
given  the  same  distribution  as  the  Emergency 
Notification  List.  The  severity  of  the  disaster 
defined,  as  requiring  the  Action  Plan,  must  be  equal  to 
or  less  than  the  following  guideline:  Any  occurrence 
resulting  in  an  estimated  time  for  full  recovery  of 
files,  software,  hardware,  personnel,  etc.,  of  more 
than  30  hours,  or  if  an  estimate  is  not  possible  or  is 
uncertain . 

The  production  concept  behind  the  guideline  is  to  start 
the  disaster  recovery  process  promptly,  recognizing 
that  the  process  can  be  stopped  readily  if  the 
emergency  turns  out  to  be  more  easily  remedied  than 
originally  thought. 

4.  A  signed  memo  of  agreement  with  the  back-up  facility, 
in  necessary  detail,  and  providing  reserved  capacity 
for  terminals  and  other  data  communications  essential 
to  disaster  recovery. 
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Section  2. 

Off-Premises  Storage 

The  off-premises  storage  must  have  adequate  security,  proper 
temperature  and  humidity,  be  accessible  at  all  times,  be  located 
within  reasonable  driving  time  from  the  ADP  computer  center,  and 
be  reasonably  well  isolated  from  disasters  that  are  likely  to 
occur  at  the  ADP  computer  center . 

A.  Production  Control.  Move  all  files/records  that  are 
essential  to  disaster  recovery  to  off-premises  storage. 

B.  Librarian .  Maintain  up-to-date  records,  of  all 
files /records  contained  in  off-premises  storage. 
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Section  3. 
Action  Plan 


The  Action  Plan  outlines  the  basic  responsibilities  in  the  event 
of  a  disaster  for  providing  temporary  service  while  the  computer 
center  is  inoperative,  plus  simultaneous  reconstruction  of  the 
computer  center  hardware,  software,  and  records. 

A.  All  Personnel  -  Disaster  Notification  and  Mobilization. 
Operators  and/or  software  personnel  working  in  the  Computer 

Center  are  to  immediately  notify  the  Chief  of  the  Disaster 
Team,  or  his  designated  alternate,  upon  knowledge  of  a 
disaster.  The  recalled  disaster  staff  will  immediately 
begin  mobilizing  personnel  on  the  Personnel  Recovery  List, 
and  initiate  the  following  Action  Plan  steps: 

B.  Disaster  Staff.  The  disaster  staff  will  manage  the  disaster 
recovery  Action  Plan. 

C.  Librarian .  Provide  to  Production  Control  proper  generations 
of  files,  programs,  operations  manuals,  program  run  records, 
etc.,  for  complete  initialization  and  running  capabilities 
at  the  back-up  facility. 

Provide  same  material  as  above  for  reconstructed  ADP 
computer  center  for  initialization  and  running  capabilities. 

Continuously  maintain  off-premises  storage  for  tapes,  etc., 
generated  at  back-up  facility. 

D.  Production  Control .  Transportation  of  all  materials,  etc., 
from  off-premises  storage  to  back-up  facility.  Provide 
proper  documentation,  special  batch  control  to  replace 
on-line  terminal  up-dates,  etc.,  as  required  for  back-up 
facilities  operations.  Notify  users  on  special  scheduling 
requirements,  delayed  testing,  etc. 

E .  Scheduling  . 

1.  Modify  the  Disaster  Standby  Priority  list,  as  required 
by  circumstances,  and  release  to  Production  Control  and 
Operations . 
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Section  3  (Cont . ) 

Coordinate  with  the  back-up  facilities  scheduling 
function  to  accomplish  an  agreed  upon  working 
arrangement . 

2.  Prepare  a  daily  run  schedule  for  the  back-up  site. 
Prepare  a  daily  central  schedule  (as  computer  center 
goes  back  into  operation). 

Describe  proper  use  of  priority  classes  to  operators. 

3.  Advise  Production  Control  of  all  materials  to  be 
transported  between  back-up  facility  and  Denver  for 
every  trip  each  day. 

4.  Schedule  all  emergency  requests;  clear  with  Disaster 
Recovery  Staff. 

5.  Prepare  schedules  for  on-line  terminal  hours  and 
distribute . 

6.  Prepare  personnel  working  hours  schedule;  clear  with 
Disaster  Recovery  Staff. 

7.  Prepare  all  schedules  for  eventual  resumption  of  tests, 
compiles,  low-priority  production,  etc. 

F.  Software .  Assist  in  initialization  of  back-up  facility. 

Test  initialization.  Arrange  for  hook-up  of  emergency 
terminals  if  necessary.  Assist  in  all  problem  solutions. 

G.  Operators .  Initialize  back-up  facility.  Test  with  Software 
assistance.  Run  according  to  scheduling  priorities  and 
direction . 

H.  Security  Officer.  Function  as  a  member  of  Disaster  Recovery 
Staff.  Monitor  security  of  movement  of  data,  etc.,  to  and 
from  back-up  facility  and  Denver,  establishing  working 
ground  rules. 

Maintain  liaison  with  Security  Officer  at  back-up  facility. 

I .  Rehabilitation  and  Coordination  (R  and  C)  Team.  A 
Rehabilitation  and  Coordination  Team  will  be  made  up  of  the 
following  personnel,  or  their  predetermined  alternates  if 
the  prime  members  are  missing  at  the  time  of  disaster. 
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Section  3  (Cont.) 

*  Chief,  Branch  of  Computer  Operations  (Team  Head). 

*  ADP  Security  Officer. 

*  Contract  Review  Supervisor  (Asst.  Team  Head). 

*  Performance  Evaluation  Analyst. 

*  Supervisor,  Technical  Support. 

*  Librarian. 

*  1st  Shift  Supervisor,  Operations. 

The  R  and  C  Team  will  guide,  direct,  acquire  equipment, 
subcontract  work,  etc.,  as  is  required  to  effectively  and 
efficiently  reconstruct  and  rehabilitate  the  computer 
center . 
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